Re: ECC vs RSA, and Similar Conflicts

On May 22, 2012, at 11:54 AM, Eric Rescorla wrote:

> On Tue, May 22, 2012 at 2:23 AM, David McGrew <mcgrew@cisco.com> wrote:
>> On May 10, 2012, at 10:36 AM, Anil Saldhana wrote:
>> 
>>> Giving direct access to private keys to the JS api is trouble.
>>> 
>>> I support David's thoughts on just allowing references to IDs of Private Keys.
>> 
>> +1
>> 
>> It will also be important that the API itself not allow manipulations of the secret and private keys that allow an attacker to cause one of those keys to be revealed by executing a (possibly convoluted) sequence of operations on it, as has been shown to be the case for PKCS#11 (see for instance <http://www.lsv.ens-cachan.fr/~steel/pkcs11/>)
> 
> David,
> 
> I think this is actually an argument *against* key isolation.
> 
> As soon as protecting the keys becomes a system invariant, then the
> introduction of any new API call requires extensive cryptographic
> review. As I've been putting it lately, "every time you want to add
> a new API point, you need to call Dan Boneh".
> 
> This isn't to say that there is no use for key isolation, but that making it
> a security guarantee of the system is quite expensive in terms of
> design cost.

I take your point, and I think the worst possible situation would be if the API added complexity intended to isolate secret/private keys, but then failed to achieve that isolation because of unanticipated attacks.   But I also think there is a wide range of design possibilities between the two extremes of "no functions provide key isolation" and "all new functions require an expert to run a theorem prover to verify the safety of the API".

David

> 
> -Ekr

Received on Tuesday, 22 May 2012 18:19:35 UTC