[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Aug 2015 23:22:41 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: auditing our use of FMT_* flags (was: more robustness)
Kai,
On Fri, Aug 14, 2015 at 10:34:31PM +0300, Solar Designer wrote:
> This is tricky. Tripcodes are defined such that characters 2 and 3 of
> passwords form a salt for the classic DES-based crypt(3), aka descrypt.
> The latter is defined to operate on 64 valid characters only, from the
> set [./0-9A-Za-z]. Tripcodes additionally define a translation table
> for some characters that are not valid in salts to those that are valid:
>
> char *from = ":;<=>?@[\\]^_`";
> char *to = "ABCDEFGabcdef";
>
> For the rest, including all 8-bit ones, behavior is undefined.
> In practice, it depends on whatever implementation of crypt(3) a given
> system uses. There are at least two widespread mappings of invalid salt
> characters onto numeric salt values. JtR implements one of those. Your
> finding suggests that this one treats 8-bit characters such that their
> 8th bit matters.
This is DES_std.c: DES_atoi64[]. As you can see, the first half of this
table isn't the same as the second half. One starts with "18, 19, 20, 21,
...", the other with "5, 6, 7, 8, ..." It just happens so. We might want
to see what invalid salt handling is currently most common for descrypt
hashes in the wild, and revise this table accordingly, at which point it
might happen that it'd be symmetric wrt the 8th bit. But not right now.
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
