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 cmart...@zynga.com On 7/27/11 10:11 AM, "Adam Barth" <aba...@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 <cmart...@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 >> cmart...@zynga.com >> >> >> >> >> On 7/27/11 7:53 AM, "Adam Barth" <aba...@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@lists.webkit.org >>>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
