lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 8 Mar 2014 09:12:24 +0400
From: Solar Designer <>
Subject: Re: [PHC] TigerKDF paper and code ready for review

On Fri, Mar 07, 2014 at 11:24:56PM -0500, Bill Cox wrote:
> After three glasses of wine, all I can say is... ouch, that hurts!

Oh, I really didn't mean to keep you working today.  I thought you'd
read my follow-up when you're sober. ;-)

> So, this is a good time to do personality analysis of your code,
> because normally I'd have slightly more sense.

Thanks.  That's fun, and it could also be useful.

> You indent by tab,
> which is one keystroke, there are very few comments, and you like 1
> letter variable names.  This indicates you feel typing speed is a
> limiting factor, and I bet you type pretty fast.

Oh, typing speed is not a factor at all.  Having only few comments and
using short variable names (except where a longer name is justified) are
actually for clarity.  I like it when more of the actually important
stuff is easily seen, without distractions to comments on obvious things
and over-long identifiers.  I also like self-explanatory code; before
writing a comment, I think "can I change the code such that this comment
wouldn't be necessary?"  This contributes to needing fewer comments.

I intend to do a review/cleanup pass over the code before "releasing"
it, though - and this may include addition of a handful of comments on
things that I might find likely unclear to others.

BTW, while the coding style you see in escrypt mostly matches mine, some
of it is actually from original scrypt.  I didn't want to reformat
source code lines from scrypt that I could keep intact, so instead, for
my work on escrypt, I adopted (or at least tried to adopt) Colin's
conventions for the (very few) things that I normally write differently.

> I read a very long
> function you wrote that could have been broken up, but that would also
> have slowed you down, as there were no common sub-functions to factor
> out, or you would have.

Slowing me down would be OK; making the resulting code more complicated
would not be.

And yes, I would have factored out common sub-functions if some were
present, and if that seemed do-able and beneficial.

As I had mentioned, two of the very long functions I am really unhappy
about are smix1() and smix2() in -sse; I need to de-/re-optimize those.
In -ref and -nosse, I think they're OK.

> None of this lack of commenting or long
> variable names are useful to you, because the code is perfectly clear
> without it.

That's the intent.

> Given all this, I'd bet you also have at least two
> screens.  One just wouldn't be enough.

While working on escrypt, I usually have two code revisions on nearby
xterms (on one monitor), because this is about making (and often
reverting) experimental changes, and also because after making changes
to one of the three implementations (-ref, -nosse, or -sse), I then need
to make equivalent (but suitably different) changes to the other two.

> You APIs in header files are very clear, and I bet you focus on that.

Yes, APIs are important.

> I've seen code like this before, just one other time, and I've read a
> crazy amount of code.

Hmm.  I don't think code like Colin and I write is that uncommon.

> I went to work for Ken in 1996 at Synplicity, hoping I could learn to
> be more like him, but my brain isn't wired like his.  I've got some
> fun stories about him.  I was the first coder he hired, though there
> were 24 employees already, because he could handle the coding load by
> himself for a long time.  There were 350,000 lines of hardware
> description language synthesis code, and he hired me to help out with
> it.  I opened one of the more interesting files (the factoring engine,
> which blew doors on competitors), which was 2,400 lines long, most of
> which being 1 function, with no comments, tabs for indentation, and he
> actually ran out of good 1-letter variable names and started using
> 2-letter names.  I figured he must just put the comments somewhere
> else, like header files, so I greped the whole code base for /*...
> there was just one, and it said "This is a hack".

This is actually much more similar to Roman Rusakov's DES S-box
expression optimizer code, which was indeed a hack (and a great one at
that).  I hope escrypt is substantially different (not meant to be that
much of a hack, not even at this stage).

> He had two monitors covered in maybe a couple hundred icons, most of
> which ran custom scripts.  He had the build icon in release mode, and
> a an icon to publish for customer download, but no debug icon I ever
> saw him use (it was probably a lonely unused icon).

As I hope you realize, with escrypt this is actually mostly testing now.
Even when a change happens to work as expected right away, I nevertheless
do test it, since that's the whole point.


Powered by blists - more mailing lists