Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8902 > unrolled thread

Simple alphanumeric "encryption"?

Back to article view | Back to comp.lang.java.programmer

Contents

  Simple alphanumeric "encryption"? "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-10-17 18:16 +1100
    Re: Simple alphanumeric "encryption"? Arne Vajhøj <arne@vajhoej.dk> - 2011-10-17 08:13 -0400
      Re: Simple alphanumeric "encryption"? Travers Naran <tnaran@gmail.com> - 2011-10-18 06:47 -0700
        Re: Simple alphanumeric "encryption"? David Segall <david@address.invalid> - 2011-10-20 00:36 +1100
        Re: Simple alphanumeric "encryption"? Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 16:13 -0500
    Re: Simple alphanumeric "encryption"? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-17 12:27 +0000
    Re: Simple alphanumeric "encryption"? Tom Anderson <twic@urchin.earth.li> - 2011-10-17 16:45 +0100
      Re: Simple alphanumeric "encryption"? "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-10-18 14:18 +1100
        Re: Simple alphanumeric "encryption"? "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-10-18 14:25 +1100
        Re: Simple alphanumeric "encryption"? Lew <lewbloch@gmail.com> - 2011-10-18 08:43 -0700
        Re: Simple alphanumeric "encryption"? Tom Anderson <twic@urchin.earth.li> - 2011-10-20 20:57 +0100
    Re: Simple alphanumeric "encryption"? B1ll Gat3s <wm.g4t3s@m1cr0s0f7.c0m> - 2011-10-17 21:33 -0400
    Re: Simple alphanumeric "encryption"? Roedy Green <see_website@mindprod.com.invalid> - 2011-10-20 13:32 -0700
    Re: Simple alphanumeric "encryption"? Roedy Green <see_website@mindprod.com.invalid> - 2011-10-20 13:36 -0700

#8902 — Simple alphanumeric "encryption"?

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)
_________________________________________________
Qu0llSixFour@gmail.com
[Replace the "SixFour" with numbers to email me] 

[toc] | [next] | [standalone]

#8906

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

[toc] | [prev] | [next] | [standalone]

#8946

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. :-)

[toc] | [prev] | [next] | [standalone]

#8996

Travers Naran <tnaran@gmail.com> wrote:

>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. :-)

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.

[toc] | [prev] | [next] | [standalone]

#9676

On 10/18/2011 9:47 AM, Travers Naran wrote:
> 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. :-)

I am not qualified to write root kits etc..

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#8908

Qu0ll <Qu0llSixFour@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.

[toc] | [prev] | [next] | [standalone]

#8920

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

[toc] | [prev] | [next] | [standalone]

#8938

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

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. 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.

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

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.

--
And loving it,

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

[toc] | [prev] | [next] | [standalone]

#8939

"Qu0ll"  wrote in message 
news:pIKdnalVhP-ubQHTnZ2dnUVZ_hCdnZ2d@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.

--
And loving it,

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

[toc] | [prev] | [next] | [standalone]

#8955

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

[toc] | [prev] | [next] | [standalone]

#9050

On Tue, 18 Oct 2011, Qu0ll wrote:

> "Tom Anderson"  wrote in message 
> news:alpine.DEB.2.00.1110171515220.10855@urchin.earth.li...
>
> 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. 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.
>
> ------------------------------------------------------------------------------------------------
>
> 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?

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

[toc] | [prev] | [next] | [standalone]

#8934

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.

[toc] | [prev] | [next] | [standalone]

#9052

On Mon, 17 Oct 2011 18:16:48 +1100, "Qu0ll" <Qu0llSixFour@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.

[toc] | [prev] | [next] | [standalone]

#9053

On Mon, 17 Oct 2011 18:16:48 +1100, "Qu0ll" <Qu0llSixFour@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.
-- 
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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web