Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 09 Jan 2014 04:14:45 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Should several more hash formats be changed from using
 hex to base64 before releasing unstable and bleeding?

On 2014-01-09 00:41, Frank Dittrich wrote:
> AFAIK, the latest jumbo that has been officially released has been
> 1.7.9-jumbo-7.
>
> This version did not have several formats that use extremely long hashes
> which could be made shorter by converting hex encoding to base64 encoding.
> (If we plan such a change after the current unstable-jumbo or
> bleeding-jumbo have been officially released, we might need to support
> both encodings for backwards compatibility.
>
> That's why I think, the earlier we decide to change formats, the better.
> Of course, when we change the canonical representation of a particular
> hash format, all implementations need to be adjusted (e.g., several
> different CPU implementations + OpenCL + CUDA).

> I know that changing the canonical format representation isn't fun,
> especially not if you have a format2john and multiple implementations
> that need to be changed as well.
> However, if we change certain formats before they appear in an
> "official" jumbo release, the change will be less painful than a change
> after the format has been released.
> (If we decide to change certain formats, I suggest changing the CPU
> implementations first, hunting down any new bugs in valid(), and then
> adjusting the GPU formats.)

I agree and I thought we had an open issue for this but it turns out it 
was baked into https://github.com/magnumripper/JohnTheRipper/issues/311 
which was closed after fixing LUKS. We could edit that issue and make it 
a task list.

However, 1500 characters of hex becomes 1000 characters of Base64 - it 
doesn't help that much. LUKS still has one source code line of 85 KB. 
Some editors and compilers can't handle that and it exceeds the 
guaranteed supported static string length (although that limit is pretty 
low, iirc lots of other things in our tree exceed it).

magnum

Powered by blists - more mailing lists

Your e-mail address:

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