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 <cmart...@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 > 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
