[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120805052219.GH544@brightrain.aerifal.cx>
Date: Sun, 5 Aug 2012 01:22:20 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: musl 0.9.3 released
On Sun, Aug 05, 2012 at 12:56:24AM -0400, idunham@...abit.com wrote:
> > On 08/05/2012 03:00 AM, idunham@...abit.com wrote:
> >>
> >>> I'd also like to finish and integrate the rest of rdp's porting work
> >>> (mips64, ppc, and microblaze) and possibly get an x32 (32-bit ABI on
> >>> x86_64) port underway, and integrate additional hash function support
> >>> (blowfish, sha, md5) for crypt.
> >> All of these sound good.
> >> I'm not sure about whether many people would be interested in x32,
> >> though?...
> > x32 is the latest hype and a lot of work has recently been put into
> > toolchain, kernel and debugger support.
> > this is probably a good opportunity to get the attention of early
> > adopters.
>
> Well, actually, a lot of work has recently been _finished_, so
> glibc/binutils/kernel/... now have stable support. Early adopters have
> been using it for a year or few.
> The adoption has been rather minimal as far as I can tell; what I meant to
> ask was more if any current/potential users of musl intend to use it if
> possible. In other words, if you or someone you are in commmunication with
> is going to start using musl x32 for any reason besides "It happens to be
> supported".
If I were going to switch to x86_64 cpu, which I will probably do in
the next few years, x32 would certainly be appealing. Not decided for
sure, but it seems very nice to get all the important benefits of a
64-bit cpu with none of the bloat. I think this sounds appealing to
a big part of musl's target userbase too...
> >> Something other than standard crypt (isn't that DES, which can be
> >> cracked in a day on the right machine?) would be one of the more
> >> interesting ones from my perspective. Remembering the recent test
> >> results, I'd be hoping for bcrypt as well (it's where OpenCL
> >> cracking gets the least benefit).
> > which test results are you referring to ?
>
> best discussion:
> http://openwall.info/wiki/john/GPU
> http://openwall.info/wiki/john/GPU/bcrypt
>
> There are several other articles you can find, if you look up john the
> ripper gpu hash bcrypt (or anything reasonably similar...)
>
> > for my part, i think simple DES crypt() in the libc is sufficient.
> > busybox 1.20+ ships with a decent set of hash algos to use for login, so
> > the libc crypt code isnt used anyway
> 1. Is busybox the only login we want to support?
No, and in fact login is utterly useless. It never gets used unless
you're logging in at the physical console, or with some horribly
insecure legacy protocol like telnet...
> 2. Is login (or similar) the only place crypt is used?
No, sshd is the main place it's used.
> 3. Do we want to rely on the busybox internal code?
> 4. This is "If you plan to add hashes (which Rich has stated
> that he hopes to do, in the original post), please consider
> making bcrypt one of them."
How bloated is it? Sadly crypto folks seem to love giant bloated
tables...
Rich
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.
