> Looks pretty good. One likely problem is that the perl module processes
> the key slightly differently. I'm not really a perl expert, but it
> looks like perl treats the $passphrase argument as a 48-byte hex-ASCII
> encoded key.
> As an added twist, the perl pack function will just use
> the last four bits of the ASCII code for non-hex characters, i.e. if
> the letter 'k' is put in $passphrase it will be treated as if it was
> the hex character 'b'.
I cant really follow this. How is a non-hex character transformed into a
hex one? Or more specific, how is k transformed to b?
b is ascii 98 is binary 0110 0010
k is ascii 107 is binary 0110 1011
The first nibble is identical, but the second isnt. How would this work?
> For example; your java key is the 24 byte array new byte [] { 'k', 'e',
> 'y', ' ', ..., ' '}; To get the same key in perl you set $passphrase to
> '6a6579202020...' on out to 48 characters. Conversely, if in perl you
> set $passphrase to 'key', the equivalent java key is the 24-byte array
> new byte[] {0xb5, 0x90, 0x0, ..., 0x0}.
The problem here is however that 0xb5 and 0x90 arent valid values for a
byte value (they are larger than 128).
> Another nit is the use of String.getBytes() without specifying an
> explicit encoding, and similarly the use of the String constructor
> without specifying an encoding.
I agree, but in my testing it shouldnt matter also because getBytes()
returns the correct values in this case - just for testing.
Thanks very much,
Alexander
John W. Kennedy - 24 Aug 2006 17:16 GMT
>> Looks pretty good. One likely problem is that the perl module processes
>> the key slightly differently. I'm not really a perl expert, but it
[quoted text clipped - 13 lines]
>
> The first nibble is identical, but the second isnt. How would this work?
Look closely at the "k". Binary 01101011 is hex 6B.

Signature
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
Greg Stark - 25 Aug 2006 01:29 GMT
> > Looks pretty good. One likely problem is that the perl module processes
> > the key slightly differently. I'm not really a perl expert, but it
[quoted text clipped - 11 lines]
> b is ascii 98 is binary 0110 0010
> k is ascii 107 is binary 0110 1011
It is confusing, and I'm not really a perl expert so I could be wrong.
The perl documentation for the encryption function does not say this,
but the source code I think proves that it is expecting only hex-ascii
characters in the $passphrase argument, not arbitrary strings. You give
two hex-ascii characters for every byte of key. However, it does not
complain if you give it a $passphrase that is not of this form. So,
what happens if it gets a $passphrase that is something like "key", or
"myPassPhrase"? I thought I understood from this blurb from the perl
documentation for the pack function:
"...The h and H fields pack a string that many nybbles (4-bit groups,
representable as hexadecimal digits, 0-9a-f) long.
Each byte of the input field of pack() generates 4 bits of the result.
For non-alphabetical bytes the result is based on the 4
least-significant bits of the input byte, i.e., on ord($byte)%16. In
particular, bytes "0" and "1" generate nybbles 0 and 1, as do bytes
"\0" and "\1". For bytes "a".."f" and "A".."F" the result is compatible
with the usual hexadecimal digits, so that "a" and "A" both generate
the nybble 0xa==10. The result for bytes "g".."z" and "G".."Z" is not
well-defined. ..."
> The first nibble is identical, but the second isnt. How would this work?
>
[quoted text clipped - 6 lines]
> The problem here is however that 0xb5 and 0x90 arent valid values for a
> byte value (they are larger than 128).
Oops, my bad, that should have been new byte[] {(byte) 0xb5, (byte)
0x90, 0x0, ..., 0x0}.
On second thought, I think this is a poor example, and you should
really test it with valid $passphrase. As a very simple example, you
can try both the perl and java with the all zeros key. Give perl a
$passphrase of "000000000000000000000000000000000000000000000000". If
that works, you can try progressively more complex values until you are
confident you understand the workings. If not, let me know. Maybe I'll
install perl and see if I can play with it myself.
> > Another nit is the use of String.getBytes() without specifying an
> > explicit encoding, and similarly the use of the String constructor
[quoted text clipped - 5 lines]
> Thanks very much,
> Alexander
Oliver Wong - 08 Sep 2006 22:26 GMT
>> Looks pretty good. One likely problem is that the perl module processes
>> the key slightly differently. I'm not really a perl expert, but it
[quoted text clipped - 13 lines]
>
> The first nibble is identical, but the second isnt. How would this work?
The hexadecimal value 'b' is equal to the decimal value '11', which is
equal to the binary value '1011' which is the lower half of the ASCII
representation of the character 'k'.
So char 'k' -> 0xb.
- Oliver