cmartens at zynga.com
Wed Jul 27 02:29:55 PDT 2011
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.
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?
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.
>On Wed, Jul 27, 2011 at 12:59 AM, Christoph Martens <cmartens at zynga.com>
>> 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
>> 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
>> 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