Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 30 Mar 2015 11:12:39 +0200
From: Frank Dittrich <frank.dittrich@...lbox.org>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists

On 03/25/2015 09:24 PM, Agnieszka Bielec wrote:
> 
> Pomelo_testvectors.txt is in the main directory. I've also added it to the 
> fmt_tests structure. I've modified pamelo.c in the main directory 
> to generate ciphetexts and there is no way to test it. 

Do you mean there's no way to use the test vectors in
Pomelo_testvectors.txt to verify your implementation?
If yes, then this is probably due to

(master)POMELO $ grep "password length" Pomelo_testvectors.txt |sort
|uniq -c
   4096 The password length is 128 bytes;
(master)POMELO $ grep "password is" Pomelo_testvectors.txt |sort |uniq -c
    512 The password is zero, except that the first byte is 0
    512 The password is zero, except that the first byte is 1
    512 The password is zero, except that the first byte is 2
    512 The password is zero, except that the first byte is 3
    512 The password is zero, except that the first byte is 4
    512 The password is zero, except that the first byte is 5
    512 The password is zero, except that the first byte is 6
    512 The password is zero, except that the first byte is 7

That is, these test have been generated using passwords of length 128,
but all bytes except the first byte are `\0'.
You are right, john can't handle such passwords.
Unless, of course, we assume that POMELO will always work with a
password length of 128.
Then we could pass any string as a password, and the POMELO format would
need to convert this into a 128 byte password with trailing '\0'
"characters".
But I think this assumption is probably wrong.
Using arbitrary input as passwords makes sense if you intend to use key
files with random data, but not really for user specified passwords.

While we cannot handle arbitrary random data (including '\0' characters)
as passwords, we must be able to handle arbitrary random data as salts.

(master)POMELO $ grep "salt length" Pomelo_testvectors.txt |sort |uniq -c
   4096 The salt length is 16 bytes;
(master)POMELO $ grep "salt is" Pomelo_testvectors.txt |sort |uniq -c
    512 The salt is zero, except that the first byte is 0
    512 The salt is zero, except that the first byte is 1
    512 The salt is zero, except that the first byte is 2
    512 The salt is zero, except that the first byte is 3
    512 The salt is zero, except that the first byte is 4
    512 The salt is zero, except that the first byte is 5
    512 The salt is zero, except that the first byte is 6
    512 The salt is zero, except that the first byte is 7

So, I think, it is wrong to use a text sting as salt representation.
Instead, we have to use either hex encoding, base64 encoding, or
something else to represent the salt.

So, a salt length of 16 with only the first byte being the character '1'
could be encoded as 31000000000000000000000000000000.

Frank

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ