Re: Smart Card support. Re: Request for feedback: DOMCrypt API proposal

On Thu, Jun 9, 2011 at 1:40 PM, David Dahl <ddahl@mozilla.com> wrote:
>> Performing keyed cryptographic operations (as opposed to hash
>> functions) requires keys. Whence the keys? And what are their
>> semantics? This is where trust comes in.
>
> Right. The concept that has evolved is where the origin generates the keys and only that origin can access that key pair. For symmetric keys, we will need some kind of index of wrapped keys, and the application only needs to know the key's ID to use it - as well as - perhaps - the enduser being able to unwrap the key.
>
> I think the API gives application developers a couple of methods for helping deal with symmetric key use (and distribution via various application methods that are dreamed up).

So you presume a client-side (browser or platform) softtoken or smartcard?

How are the keys to be distributed or exchanged?

>> Aha! You're presuming that you have a secure channel. Let's say you
>> do have one. Now what? Why do any crypto in the script? To avoid
>> sending passwords to the server??
>
> There is a really great use-case here: the server operator does not want to hang on to any plaintext data the user is entering into the application. This is huge from the standpoint of data breaches.

On which side?  If on the server-side, how does JS crypto help?  Or
did you mean that the server stores ciphertext for which it knows no
keys?  I could see this being useful for dealing with user profiles
that store credit card numbers, but which require the client to
decrypt such information with client-side keys.

Alright, you've found a use for JS crypto for which I can get
on-board.  Although key management is a problem (e.g., if derived from
a password then an attacker could mount offline dictionary attacks
after acquiring a copy of the ciphertext).

(Or did you mean on the client-side?)

Nico
--

Received on Thursday, 9 June 2011 19:56:59 UTC