[webkit-dev] DOMCrypt

[Christoph Martens]

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
>>
>>