abarth at webkit.org
Wed Jul 27 01:11:47 PDT 2011
My sense is that the Mozilla folks want to start with the simple
building blocks first and then work up to more complicated things like
interacting with OS key stores and smart card readers.
DOMCrypt is also useful for protecting data at rest, which isn't
something you can do with TLS. For example, imagine that a web site
wants to store a bunch of sensitive data on the client. The site can
encrypt the data using DOMCrypt and then keep the KeyID off-device
(e.g., in the cloud or in escrow). Later, the site can reunite the
KeyID with the encrypted data on the client in order to decrypt.
As a more concrete example of the above, consider a service like
LastPass that wants to store your passwords (encrypted) on the client
and never wants to touch your plaintext passwords on the server.
These use cases all involve the public key encryption/decryption
functionality. The hashing and MACing operations are somewhat lower
level building blocks, but they seem like an easier place to start.
On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens <cmartens at zynga.com> wrote:
> Hey Adam,
> I thought it might make sense to let the user specify a private key file
> (e.g. an RSA-key) that is in the browsers KeyChain.
> Would that make sense to have it implemented in the DOMCryptAPI?
> Otherwise I can't see many use cases, because I think encryption on a high
> OSI layer just doesn't make sense for me.
> If someone is able to sniff SSL/TLS encrypted packages due to nulling he
> will also be able to collect enough generated data to see how the hashing
> on the Browser-side works and which one will be the next hash generated -
> thanks to cuda and ati stream.
> But that's just my personal opinion on that.
> Greets from Germany,
> Christoph Martens
> Freetime Cyanogen developer, kernel.org core dev and Metasploit hacker
> Zynga Game Germany GmbH
> An der Welle 4
> 60322 Frankfurt, Germany
> cmartens at zynga.com
> On 7/27/11 7:53 AM, "Adam Barth" <abarth at webkit.org> wrote:
>>As some of you are probably aware, Mozilla is experimenting with
>>exposing some basic cryptographic primitives to web applications:
>>I wanted to get a sense from the WebKit community about how interested
>>we are in implementing this feature. My sense is that this API is
>>fairly early in it's lifecycle, so one perspective is that we should
>>wait for Mozilla to experiment for a bit longer and revisit this
>>question once the design is further along (e.g., submitted to the W3C
>>Another perspective is that there are some simple parts of the API
>>that we should implement now, and we can grow into the more involved
>>parts of the API as they mature. For example, the CryptoHash
>>interface can be implemented independently of the rest of the API and
>>provides value by itself.
>>webkit-dev mailing list
>>webkit-dev at lists.webkit.org
More information about the webkit-dev