Simple alphanumeric "encryption"?

[Qu0ll]

I need to be able to encrypt/code an arbitrary string of up to about 50
alphanumeric characters into a string that also contains only alphanumeric
characters. All of the encryption algorithms I have looked result in
strings with non-ASCII characters in them (when the resulting bytes are
turned into a string) which is not suitable.

Is there a simple way to do this? It must be able to successfully be
decrypted as well but doesn't need to be very sophisticated or extremely
secure.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llS...@gmail.com
[Replace the "SixFour" with numbers to email me]

[Arne Vajhøj]

On 10/17/2011 3:16 AM, Qu0ll wrote:
> I need to be able to encrypt/code an arbitrary string of up to about 50
> alphanumeric characters into a string that also contains only
> alphanumeric characters. All of the encryption algorithms I have looked
> result in strings with non-ASCII characters in them (when the resulting
> bytes are turned into a string) which is not suitable.
>
> Is there a simple way to do this? It must be able to successfully be
> decrypted as well but doesn't need to be very sophisticated or extremely
> secure.

Why not use standard encryption *and* base64?

Otherwise there is always Caesar and Vigenere obfuscation
algorithms.

Arne

[Andreas Leitgeb]

Qu0ll <Qu0llS...@gmail.com> wrote:
> I need to be able to encrypt/code an arbitrary string of up to about 50
> alphanumeric characters into a string that also contains only alphanumeric
> characters. All of the encryption algorithms I have looked result in
> strings with non-ASCII characters in them (when the resulting bytes are
> turned into a string) which is not suitable.
>

I guess "base64" is a search term, that might get you further.

[Tom Anderson]

On Mon, 17 Oct 2011, Qu0ll wrote:

> I need to be able to encrypt/code an arbitrary string of up to about 50
> alphanumeric characters into a string that also contains only alphanumeric
> characters. All of the encryption algorithms I have looked result in strings
> with non-ASCII characters in them (when the resulting bytes are turned into a
> string) which is not suitable.
>
> Is there a simple way to do this? It must be able to successfully be
> decrypted as well but doesn't need to be very sophisticated or extremely
> secure.

Oddly, i have a paper called "Ciphers with Arbitrary Finite Domains"
sitting in my reading queue right not.

You have at least two basic routes of attack here.

First, recognise that alphanumerism is just an encoding of a general bit
string. Decode the alphanumeric string into a bit string (by taking it as
a base-36 or base-62 number, or whatever), encrypt that, then re-encode
it. BigInteger has a constructor which takes a string and a radix, and a
toString method which takes a radix. So:

String s = "1sxjxyr5owpxwzmax6pyv1wgjpfuc4iadgrzhjpcameipq5sk";
BigInteger i = new BigInteger(s, 36);
i = i.multiply(BigInteger.valueOf(2)); // this is a very poor kind of encryption
System.out.println(i.toString(36));

BigInteger can also be converted to and from a byte[], which you can
subject to proper encryption. You will need to be a bit careful, because
conversion to an alphanumeric string will remove any leading zeroes, so
you may need to pad. Also, the numbers may be negative, in which case the
alphanumeric strings will have a leading minus sign. You might prefer to
write your own conversion between bytes and digits, to avoid these
problems.

Note that using a proper cipher involves generating an initialisation
vector (IV) for each message you encrypt, which you will then need to send
along with the ciphertext. That's going to be slightly annoying, since the
alphanumerically encoded IV is likely to be just as long as your message.

Second, come up with a cipher that works directly on alphanumeric values,
rather than bit strings, and apply that to your string. I don't think this
is actually a terribly good idea, so i won't elaborate on it.

tom

--
Per Dementia ad Astra

[B1ll Gat3s]

On 17/10/2011 3:16 AM, Qu0ll wrote:
> I need to be able to encrypt/code an arbitrary string of up to about 50
> alphanumeric characters into a string that also contains only
> alphanumeric characters. All of the encryption algorithms I have looked
> result in strings with non-ASCII characters in them (when the resulting
> bytes are turned into a string) which is not suitable.
>
> Is there a simple way to do this? It must be able to successfully be
> decrypted as well but doesn't need to be very sophisticated or extremely
> secure.

Option 1: Blowfish, or whatever, followed by binhex or whatever.

Option 2: A canned solution such as PGP/GPG which can be set to "ascii
armor" mode. The graphical frontend Kleopatra has a checkbox for this.
If you've ever seen an email or news post with


-- BEGIN PGP PUBLIC SIGNATURE --
ajkdg38X3nmfnsa2906NJq ...
-- END PGP PUBLIC SIGNATURE --

or similarly, the encrypted hash used as a signature was generated with
these tools. I think they might use nonalphanumeric ASCII characters,
though, so if your requirement is really that it be alphanumeric rather
than just 7-bit clean then these won't work without modification. Open
source implementations exist though, and perhaps you can restrict the
character set in a modified version.

--
A fatal exception 0E has occurred at 0028:C0011E36 in VXD VMM(01)
00010E36. The current application will be terminated.

* Press any key to terminate the current application.

[Qu0ll]

"Tom Anderson" wrote in message
news:alpine.DEB.2.00.1...@urchin.earth.li...

Sorry about the lack of indent...

------------------------------------------------------------------------------------------------

------------------------------------------------------------------------------------------------

OK, thanks Tom for that - the first option looks promising.

I have 2 questions:

Is there any significance in the choice of numbers 36 and 62?

Can this simple method be adapted to handle input strings that contain
spaces and also to preserve the case of the inputted characters? I forgot
to mention this.

[Qu0ll]

"Qu0ll" wrote in message
news:pIKdnalVhP-ubQHT...@westnet.com.au...

> Can this simple method be adapted to handle input strings that contain
> spaces and also to preserve the case of the inputted characters? I forgot
> to mention this.

By "preserve the case" I mean so that characters in the decrypted string
have the same case as the original string. I tried your code on an input
string with mixed case and the decrypted string was all in lower case.

[Travers Naran]

On 17/10/2011 5:13 AM, Arne Vajhøj wrote:
>
> Otherwise there is always Caesar and Vigenere obfuscation
> algorithms.

Sony called. They'd like to hire you to consult on their security
problems. :-)

[Lew]

Qu0ll wrote:

> "Tom Anderson" wrote:
>
> Sorry about the lack of indent...
>
> ------------------------------------------------------------------------------------------------
> Oddly, i have a paper called "Ciphers with Arbitrary Finite Domains"
> sitting in my reading queue right not.
>
> You have at least two basic routes of attack here.
>
> First, recognise that alphanumerism is just an encoding of a general bit
> string. Decode the alphanumeric string into a bit string (by taking it as
> a base-36 or base-62 number, or whatever), encrypt that, then re-encode
> it. BigInteger has a constructor which takes a string and a radix, and a

> toString method which takes a radix. ... [snip]

> ------------------------------------------------------------------------------------------------
>
> OK, thanks Tom for that - the first option looks promising.
>
> I have 2 questions:
>
> Is there any significance in the choice of numbers 36 and 62?

Of course. It's the number of digit symbols available. Using the standard 26-letter English alphabet and the numerals zero through nine, you have 36 symbols if you restrict to one case and 62 if you allow upper and lower case.

--
Lew

[David Segall]

The OP's problem is common. All I wanted to do was to send the user a
standard "click here to confirm your request" email with the user's
email address in the URL as the key to my database.

My first thought was that I couldn't use the actual email address
because my user might be upset despite the fact that their email
address must already be included in my email. My second thought was
that _you_ might be the user. The result was that my encoding/decoding
source file is over 300 lines of pointless code because I used
(almost) standard Java encryption and base64 routines.

The "almost" in the previous sentence is because RFC 2045 includes
some characters in the base64 encoding that cannot be included in a
URL but can easily be replaced with characters that can.

[Tom Anderson]

As Lew, numerologist to the stars, has explained, yes.

> Can this simple method be adapted to handle input strings that contain
> spaces and also to preserve the case of the inputted characters? I
> forgot to mention this.

BigInteger won't go beyond 36. But there's nothing stopping you writing
your own code to use any set of characters as digits. Assemble the set,
put them in an order, count them (call that N), number them from 0 to N-1,
and use them as digits: each one is worth the digit's value multiplied by
N to the power of its position in the digit string. You know, like normal
numbers.

tom

--
Kein Mehrheit Fur Die Mitleid

[Roedy Green]

On Mon, 17 Oct 2011 18:16:48 +1100, "Qu0ll" <Qu0llS...@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>I need to be able to encrypt/code an arbitrary string of up to about 50
>alphanumeric characters into a string that also contains only alphanumeric
>characters. All of the encryption algorithms I have looked result in
>strings with non-ASCII characters in them (when the resulting bytes are
>turned into a string) which is not suitable.
>
>Is there a simple way to do this? It must be able to successfully be
>decrypted as well but doesn't need to be very sophisticated or extremely
>secure.

Cheapie encryption XOR with a password then XORs again to get it back.

You need to armour the encrypted bytes.

See http://mindprod.com/jgloss/armour.html
for various techniques. The simplest is convert to hex.

you have to strip the armour before decryption.

--
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[Roedy Green]

On Mon, 17 Oct 2011 18:16:48 +1100, "Qu0ll" <Qu0llS...@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Is there a simple way to do this? It must be able to successfully be
>decrypted as well but doesn't need to be very sophisticated or extremely
>secure.

you could use the technique from the Cryptogram puzzles in the
newspaper I used to love solving as a child.

It take a random permutation of the glyphs you permit is your message.

You then create a lookup table by letter to substitution letter to
encrypt your message. These are very easy to crack, but they have the
advantage they don't need armouring and the encrypted version is the
same length as the original.

[Arne Vajhøj]

I am not qualified to write root kits etc..

:-)

Arne

[BLD83]