[webkit-dev] DOMCrypt

[Adam Barth]

These sorts of questions are probably better discussed on the whatwg
mailing list (where there is currently a thread about DOMCrypt)
because they're general questions about the use cases and features set
of the API and not about WebKit's implementation (or
non-implementation) of the API.

Thanks for you interest.

Adam


On Wed, Jul 27, 2011 at 2:29 AM, Christoph Martens <cmartens at zynga.com> wrote:
>
> Well, I think that makes sense... But not for me. I have the opinion that
> cloud-hosted keys aren't keys anymore - right?
> I mean, man-in-the-middle attacks are the 100% use case when it comes to
> encryption due to buggy DNS-protocol that can't be updated.
>
> I also think that this is kinda interesting when it comes to signing
> uploads or files from inside a WebApp.
> It makes sense to build a JavaScript API for hashing the values - so that
> you can transfer data via unencrypted connection - which isn't smart, but
> it should gain a low level of security depending on the algorithm.
> But I wouldn't trust the hoster if there are plaintext passwords stored on
> their servers. That's kinda php4 =/
>
> Do you know which algorithms are planned to be implemented? Are there
> twofish, blowfish or similar going to be included as well?
>
> __________________________
> Christoph Martens
> JavaScript Engineer, Zynga Germany
> 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 10:11 AM, "Adam Barth" <abarth at webkit.org> wrote:
>
>>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.
>>
>>Adam
>>
>>
>>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,
>>> Chris
>>>
>>> __________________________
>>> Christoph Martens
>>> JavaScript Engineer, Zynga Germany
>>> 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:
>>>
>>>>Hi webkit-dev,
>>>>
>>>>As some of you are probably aware, Mozilla is experimenting with
>>>>exposing some basic cryptographic primitives to web applications:
>>>>
>>>>https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>>
>>>>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
>>>>standards process).
>>>>
>>>>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.
>>>>
>>>>Thoughts?
>>>>
>>>>Adam
>>>>_______________________________________________
>>>>webkit-dev mailing list
>>>>webkit-dev at lists.webkit.org
>>>>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>
>