Re: Simple alphanumeric "encryption"?
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