Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] An encryption project

Seth David Schoen schoen at
Mon Jan 28 13:13:31 PST 2013

Cooper Quintin writes:

> Paul,
> If you, as you say, "do not have much experience in breaking/testing
> encryption or the details of modern methods", I must assume that you are
> not, in fact a professional cryptographer. (That's okay! Neither am I!)
>  That being the case, I must ask you to PLEASE, PLEASE, PLEASE not
> implement any sort of cryptographic solution yourself. ESPECIALLY if it
> is intended to be used "under  circumstances that the senders life may
> depend on it being secure."

It seems even people with quite a bit of expertise often get crypto
wrong in ways that can seriously undermine the resulting system's
security.  There are lots of examples.  Sometimes the mistakes are a
matter of not understanding the state of the art or the purposes for
which a cryptographic operation is meant to be used.  Sometimes
they're about very subtle issues of information leakage that would
have been hard to anticipate; two neat examples are timing attacks
(where the amount of time that it takes for security-related code to
run may reveal information including secret keys and passwords!) and
recent attacks using information leakage from compression (whether
compression succeeds in reducing the length of a message, and by how
much, reveals information about the message's content).

Application implementers wouldn't have thought that it's bad for
different operations to take slightly different amounts of time
(it turns out that even things like testing whether
submitted_password == correct_password can be bad, because the
amount of time it takes to fail can reveal which character of
the submitted_password was wrong!); nor would they have thought
that it could be bad to compress messages before encrypting them.
But these simple decisions could lead to a complete compromise of
the system.

Another striking example about the need to understand the
properties of one's crypto tools is the simple failure modes
of ECB (traditionally the default block cipher mode!):

Check out the shadow penguin in the encrypted image. :-)

I'm optimistic that systems like NaCl are going to help with some
of this in the long run by providing useful abstractions that have
most of the security properties that application developers would
like, with immunity against many of the potential traps for the
unwary.  I'm not sure we're there yet, though.

Seth Schoen  <schoen at>
Senior Staff Technologist             
Electronic Frontier Foundation        
454 Shotwell Street, San Francisco, CA  94110   +1 415 436 9333 x107

More information about the liberationtech mailing list