[Esapi-user] [Esapi-dev] Why ESAPI crypto uses a custom serialization scheme

Kevin W. Wall kevin.w.wall at gmail.com
Sat May 1 12:42:57 EDT 2010

Chris Schmidt wrote:
> Kevin and I had several conversations about the use of crypto on the  
> client side - the end game is basically that yes, as html5 continues  
> to be implemented in browsers, specifically in the area of local  
> database and offline webapp functionality,having the abilityto encrypt/ 
> decrypt on the client side will become much mire important. One of the  
> biggest design issues I came across (which coincedentally I have not  
> solved yet) is what to do for managing the keys for said encryption.  
> This is also something that I have brought up in emails to the ff,  
> chrome, opera, safari, and ie teams via emails. The main problem here  
> is that the js sandbox is generally designed to be isolated from the  
> operating system layer (with good cause) Which means that precluding  
> any 'native' key management solution, keys would have to be stored in  
> said sandbox which is bad for many reasons.

One solution would be never to store the keys on the client at all, but use
a key exchange algorithm. In fact, it's pretty much only DAR items that
require a permanent (or more appropriately, a "long lived") encryption
key. Pretty much everything else can use temporary session keys for
symmetric encryption.  The session key itself is either encrypted with
the recipient's public key or one uses some other key exchange or a
key agreement protocol. There are many secure protocols that allow
Alice to exchange a key with Bob or that allow Alice and Bob to agree
on some new key together over an insecure comm channel. Some of them
are a bit tricky and generally involve different threat models. All
involve multiple back-and-forth trips, but they are generally used
in permanently storing a key.  It's only the DAR encrypted storage,
e.g., storing encrypted CC#s in a DB, that you need long-lived keys
for. That's where some sort of key management system is really important.

But I just can't see clients *directly* dealing with encrypted DAR
items. That rarely makes sense in my book.

Note that storing passwords locally is a an example of where the client
is should be dealing with encrypted DAR. But generally most browsers
already have a mechanism that can require those passwords to remain
encrypted until they are decrypted with a master passphrase. That
is not unlike key management systems using a Key Encryption Key (KEK)
that is used to decrypt the actual Data Encryption Keys (DEK). The
big difference is that the KEK in a key management system is a randomly
generated key and is held in a fairly controlled, secured area (often
an HSM), whereas the master key in a client browser is almost always
a manually created password (or pass phrase if you are fortunate)
and held in a questionably secure client. (And even if the browser's
master key has a relatively strong pass phrase, it generally is not going
to have as much entropy as a randomly generated 128-bit key. At least
not unless it is a string of 40+ random characters, which we all know
ain't gonna happen. This goes back to discussions last fall on why
password-based encrypted is generally a bad idea. The human element
is the weakest link.)

Anyway, getting back to JS crypto, I doubt that vanilla JS can access these
master key and the other encrypted keys the browser holds. You probably can
do it via signed JavaScript though, but why would you even need too.
Let the human element deal with entering it.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the Esapi-user mailing list