[Cryptography-dev] it's actually about ethics in key derivation

[Glyph]

> On Nov 20, 2014, at 17:18, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> So that's the motivation. Before we even start reviewing the patches, I think we need to ask ourselves about the ethical implications of writing this stuff ourselves:
> 
> * Are we qualified to do this? Some of this code, for example the PKCS#12 KDF is straight up crypto. Other parts of it are more-or-less just parsing and ASN.1 handling
> * Are we qualified to review this code?

There is no currently broadly-accepted legal, moral, or social standard for who is qualified to do this kind of thing and who isn't.  My feeling is that attempting to divide the world up according to some argument from authority into people who are "qualified" and "unqualified" is at best a waste of time and itself deeply deceptive and possibly harmful.

For example, despite OpenSSL's hilarious litany of failures, I think it's clear that we'd all be worse off if, in the face of disclosures about global state-sponsored surveillance, we had no free software with which to do widespread transport layer security, and instead had to wait for a committee of graybeard authority figures with PhDs to tell someone they're allowed to implement something.  (That's not to say that everything about OpenSSL's development has been free from ethical lapses.  There are obviously failures on that front, too.  But it's very much better than nothing.)

The question is really whether creating such software according to our collective skill and experience is potentially misleading to the public: would it be advertising a security property it does not in fact have?  The primary ethical lapse to be concerned with here is deception.  That deception might be indirect; it might be unintentional.  So some level of care is warranted.

I think that the way to address this is not to avoid implementing things, but to have a clear audit trail of who has looked at the code involved in any particular crypto implementation, whether they believe it works, and whether there are any specific concerns which might be addressed.  The simple boolean of "has this been audited" has been shown to be not terribly effective either, so saying who has audited it, when, what remediations were applied, etc, will provide a clear idea of why we honestly believe that these implementations are effective, and provide a template for future reviewers to follow.

This sort of thing has to be made at least somewhat layperson-accessible though.  Just slapping some fine print on the bottom of the box does not address concerns about potentially fooling people through omission; the caveats and limitations need to be clearly and prominently displayed.

> * Parsing and ASN.1 handling still have serious security implications
> * On the flip side, we're moving a bunch of code from dangerous C to memory safe Python.

On the KDF side, where timing attacks are a concern, and there is the possibility for input-dependent branches, I would be maybe a little concerned.  If those more well-versed in cryptographic primitives on this list agree with this concern, this is exactly the sort of thing that should be documented: something that says "while we believe that, to the best of our ability, this KDF is safe to use, we have an unverified concern that using a high-level language to implement this functionality may open the door to a timing attack, and we would like verification that the steps we have taken to mitigate this are effective..."

But on the parsing-and-handling side, I am fairly confident that the second point here completely outweighs the first and this will be a big improvement all around.

> * We actually write tests, which is probably not true of all of our backends.


This is just one attribute of the process and the team working on cryptography.

-glyph