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

[Alex Gaynor]

One thing I didn't mention: my patch, at present, uses PyASN.1, which as
far as I know hasn't been audited, and increases the surface area of
security-sensitive code.

Alex

On Thu Nov 20 2014 at 9:34:34 AM Glyph <glyph at twistedmatrix.com> wrote:

>
> > 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
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20141120/d419c6b5/attachment-0001.html>