|Timestamp||What methods of the Crypto API are you most interested in?||In your planned usage, who are the users of this API?||What data is being processed/encrypted/signed, etc?||Why is this data being processed/encrypted/signed, etc?||Why are you interested in a Web Crypto API?||Are you interested in a high-level, idiot-proof API or a low-level API?||What industry or organization are you involved with?|
|5/21/2012 10:32:37||Public Key Encryption, Symmetric Encryption||Application like webex are interested in making sure that data can be encrypted from one end users browser to the other ends users browser without the web servers in the middle (like webex) having access to the data. ||Small text messages such as IM style chat. Larger chunks of data that represent documents such as as slides. ||The webex application is trying to help two users Alice and Bob, collaborate, but Alice and Bob do not want to share the information with webex. The goal is not to stop webex from attacking Alice and Bob but to allow Alice and Bob to verify a promise that webex did not do this. It is more about detection than stopping it from happening. |
You can imagine a solution where webex helps distribute public keys, and users can check those out of bound if desired.
|a standard, cross-browser API, the speed of native crypto implementation, persistent key storage||Low-level|
|5/21/2012 11:45:33||MAC, Public Key Encryption, Symmetric Encryption||Non-Crypto Web App Developers||User Entered Data intended to be hidden from the server||In an Honest but Coercible or Honest but Curious threat model, the server will store users data, but should not be able to read it.|
This could be encrypted files, encrypted documents in a Google Docs-style app, or PKI-encrypted status updates in a Facebook-style application.
|5/21/2012 13:12:05||Signature||Financial transactions such as banking, cyber trading and credit card processing||data in web applications for financial transactions||for validations of these data||a standard, cross-browser API, persistent key storage||High-level, idiot-proof|
|5/21/2012 14:02:58||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash||Developers (experienced)||Signed, encrypted - Commercial documents|
Encrypted - Local data from HTML5 applications and other files
|Proof of signature|
Proof of transaction
Confidentiality in case of loss of device
|5/21/2012 15:08:32||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash||Primarily web application developers||Authentication data (to verify user or device)|
Digital media content that needs to be decrypted
Application data that needs to be signed
|User and device authentication|
|5/21/2012 15:24:30||Symmetric Encryption||Cable Television Interactive Application Developers||Audio/Video/Application data||To protect high-value content and services||a standard, cross-browser API||Low-level|
|5/22/2012 6:19:50||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash||Related to the the high level/love question: I think it should be both ways.|
Both advanced users and "idiot" users should be able to use this api.
|Everything from authentication schemes, to videos/sound.||We should not put any restrictions here.||a standard, cross-browser API, the speed of native crypto implementation, The security of using a common well defined API||High-level, idiot-proof|
|5/24/2012 14:37:31||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash||Application developers wanting to easily deploy crypto in their applications.||As much as possible, hopefully.||Because it's a good idea.||a standard, cross-browser API||Both. Power users obviously need low-level APIs to consume custom (read: already existing) services. However, there is a lot that could go wrong in implementations if only low-level APIs are provided. A high-level API for common tasks (like symmetric encryption) I consider to be a must-have. People are going to implement this anyway. So, you might as well provide a "batteries included" solution that covers the 95% and that people can rally behind as a standard way of doing things. By providing a high-level, idiot-proof API, you also encourage adoption of better security, which moves the web forward, IMO.||Browser Maker|
1. Sign a document hash
2. Sign a challange from a server for PKI based challenge-response handshake to perform authentication.
3. Decrypt a message using private asymmetric key.
4. Encrypt a message for someone using their pubic asymmetric key.
5. Perform hash of a large document
6. Bulk encryption of a large document using a symmetric key.
7. Bulk decryption of a large document using a symmetric key.
|The reason of each of these 7 operations listed above is as follows:|
1. signature done for non-repudiation; if you sign a document (hash) with a key that is on your smart card, you cannot later repudiate the signature.
2. By signing a challange from the server, you prove that you own the smart card, and thus prove who you are. Secure tokens such as smart cards are bound to a one person only. This provides a strong two-factor authentication on the Internet.
3. Message sent to you by others are encrypted using your public key, you and only you can decrypt it using your private key. If this key is stored on the smart card, you can be sure no once else will be able to see the message sent to you.
4. By signing a message with someones public key, you ensure that only those who have access to private key can see the message. The public keys need not be stored in hte secure element.
5. It is important to be able to perform hash of a large document quickly. Hashing is needed both during signing and signature verification. What is signed is a hash and not the actual data - which may be too big to sign.
6. Encryption of document can be important when data is stored in the cloud. Instead of sending the data in the clear and then relying on the cloud storage provider to encrypt it, some applications may want to perform client-side encryption and encrypt the data before sending to server.
7. This is the other side of coin for use case 6. When data is fetch from the server, it is encrypted. Before use, it is decrypted using the bulk decryption API on the client. The symmetric keys for both encyption and decryption can be stored in a secure element.
|persistent key storage||I feel that the API should be low level to allow applications to develop their own application logic. What is important is to be able to define the storage containers for cryptographic keys. The applications can then decide how and where the keys should persist and how they can be made available for use. We need not support all algorithms, but only the most commonly used ones - even if they are considered weak by some.||Device Maker, Application Developer, smart card and digital security|
|5/30/2012 16:49:32||Signature, Public Key Encryption, Symmetric Encryption||Web browser users who store encrypted data in the cloud.||Bookmarks, browsing history, passwords, configuration data, addons - basically any browser profile data.||The data is being encrypted locally in order to keep it completely private to the user.||a standard, cross-browser API||Low-level API that allows some interoperability with existing standards, however that is not a main focus.||Browser Maker|
|5/30/2012 17:03:57||MAC, Public Key Encryption, Symmetric Encryption, authenticated encryption||client-side encryption and MACing of data to be stored on a server. key derived (client-side) from a password||text notes and small personal information fields||to reduce the severity of the server compromise||a standard, cross-browser API||high level. fully secure by default||Internet Service, Browser Maker, Open Source Developer|
|5/30/2012 17:42:32||Public Key Encryption, Symmetric Encryption||Everyone.||Everything.||To benefit the user.||a standard, cross-browser API||Low level. The API should provide the necessary building blocks to build things that can't be built with a high-level API. A high-level idiot-proof API should be supplied by JS libraries.||Browser Maker, Application Developer, Open Source Developer|
|5/30/2012 18:13:21||Signature, Public Key Encryption||A crypto messaging client which would otherwise need to create its own (privileged) API to access platform crypto primitives which would likely not be cross-browser.||E-mails or instant messages.||User privacy. The mail server does not have an inherent need to read the user's messages unless the user desires full-text search from the server, for example.||the speed of native crypto implementation||High-level for existing (or new) standards. Specifically, easy/safe PGP-support would be important for now. The ability to support new protocols like multi-party off-the-record messaging (if further specified) would be great.||Browser Maker, Application Developer|
|5/31/2012 8:53:55||Signature, MAC, Symmetric Encryption||Authentication and secure local storage.||Mostly internal corporate data||Provide protections for data at rest and stronger authentication mechanisms.||the speed of native crypto implementation||Low level, however I can see it being abused by those who do not grasp cryptography, neither is a high level a perfect choice and forgoing the implementation of broken crypto eg. MD5/SHA1, RC4 is one hard to get correct. Default modes of operation are problematic too, I'd prefer a low level, however I'd prefer knowing that the majority of developers can use a high level api||Academia/Researcher, Internet Service|
|5/31/2012 12:40:22||Public Key Encryption||Web mail|
|5/31/2012 14:16:21||MAC, Public Key Encryption, Symmetric Encryption, Hash, RNG||Cryptocat users: https://crypto.cat||Instant messaging data as well as file attachments encoded as Data URIs.||To provide user confidentiality against both the service's servers as well as third parties/governments.||a standard, cross-browser API||Low-level. I'm a developer and I'd like the opportunity to code things with more freedom of specification.||Academia/Researcher, Application Developer, Open Source Developer, Cryptocat|
|5/31/2012 14:22:13||Signature, Public Key Encryption, Symmetric Encryption, Hash||normal human users who have lacked access to tools only currently available to Linux geeks. Also, Syrians.||local notes, message board, chat, JS code & general resource signing||feds||a standard, cross-browser API||high level||Open Source Developer|
|5/31/2012 15:31:16||Signature, Public Key Encryption, Symmetric Encryption||People who aren't developers, who are looking for something simple.|
This would either be SMS or private/direct messaging as an alternative to email.
|Simple text messages.||To help thwart man-in-the-middle attacks.||a standard, cross-browser API||Low-level, for easier implementation.||Academia/Researcher|
|5/31/2012 15:53:12||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash||open source users||Transactions, passwords...||Because they're to sensitive to be exposed on the server side....||persistent key storage||High-level||Open Source Developer|
|5/31/2012 18:16:05||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash, Bignums and prime-field / EC multiply ops||JS code operated by human beings. Not sure what you mean here.||Many small messages.||Servers are not trusted with content.||the speed of native crypto implementation||Both. High level is fine if it covers enough cases (keygen, just sign, just encrypt, authenticated-encrypt, DH negotiation in useful fields.) Backward compatibility with other cryptosystems not important.||Browser Maker, Open Source Developer|
|6/1/2012 13:06:12||PRNG||web developers||passwords and credit cards||n/a||a standard, cross-browser API||high-level. please don't provide a low-level API unless you want people to use it incorrectly||Internet Service, Browser Maker, Application Developer|
|6/1/2012 15:10:17||Pluggable frameworks, Kerberos, ZKPPs, ...||See above.||See above.||See above.||I think Web Crypto APIs are mostly -but not entirely- a disaster to be.||I think a box/unbox API could be useful as a way of keeping some user information on the user's devices instead of on the servers. For example, instead of storing credit card numbers online the server might store them on the client side encrypted in a [per-user/device!] server key. To recover the client-side user information the server might run a script on the user agent that unboxes the user information with the server key, then it can send the user information for ephemeral usage purposes on the server side, where it will then be deleted ASAP. This is clearly safer than storing the user data in the clear on the server, and safer too than storing it on the server encrypted in a key derived from the user's password.|
However, that's as far web crypto goes -- I can't think of any other use cases for which a web crypto API is an appropriate solution or for which there isn't a better alternative.
|Application Developer, Open Source Developer, Financial.|
|6/3/2012 14:56:53||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash||Our developers and potentially our customers||- Document signing|
- Encrypted local HTML5 data stores
- Encrypted local HTML5 apps
|- Confidentiality of information|
- Access security
|Low-level with access to hardware key stores/encryption engines||Device Maker|
|6/4/2012 1:39:30||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash||We foresee a wide range of use cases, but two specific examples are worth pointing out.|
One example is the case where a user has been issued a key through some out-0f-band method and must use this for authenticating requests (and perhaps encrypting them) to a remote service. This is the pattern used, for instance, in various AWS REST APIs, which require HMAC with the user's key.
The other example is the case where a user has been issued a hardware token by some out-of-band process, and must use the cryptographic keys on this token to authenticate (and possibly encrypt) transactions with a remote service. This pattern is followed, for example, with government-issued eIDs in some countries, and with bank-issued security tokens as well. Note that the transactions in this case might include enrollment for a secondary credential such as an X.509 certificate.
|See previous answer. In the examples quoted above, the data being processed is related to a request in a client-server protocol. We believe that in many cases, applications will simply use integrity primitives (HMAC or signing) and rely on the underlying TLS/SSL for confidentiality, but there will be cases where encryption is also needed.||In our first example, the objective of the cryptographic usage is to provide client user authentication in a situation where the underlying TLS/SSL transport (if present) is being used solely for server authentication.|
In our second example, the objective of the cryptographic usage is to provide the server some assurance that the transaction is genuine (e.g. approved by the user using some two-factor authentication) even in cases where the server does not necessarily believe that the client terminal is trustworthy.
|a standard, cross-browser API||While a high-level API is nice to have, we believe a low-level API is essential due to the diverse needs of applications, and therefore should be the first priority.||Browser Maker, Application Developer|
|6/4/2012 2:24:50||Signature, Public Key Encryption||3rd party developers accessing our UICC/SIM|
|payment, loyalty cards, vouchers, tickets, building access||payment: proof credit|
loyalty cards: ...
vouchers: proof it is my voucher, used only once
ticket: use only once or a period of time
building access: proof right to access building/car/service
|persistent key storage||low-level||Internet Service|
|6/4/2012 4:40:43||MAC, Public Key Encryption||End-user who connect with our devices||Media data||Security in the first hop||High level||Device Maker|
|6/4/2012 19:46:28||Signature||Mainly this API will be used in fields of the internet banking and the online securities in Korea.||Mainly money transaction data.||Non-repudiation in a money transaction.||a standard, cross-browser API||We want to use a low-level API for signing.||Government|
|6/7/2012 15:31:25||Signature, Public Key Encryption, Symmetric Encryption, Hash||employees||personal, human resources type of data||sensitivity of the data and authorization/accountability||low-level||Government|
|6/15/2012 12:19:43||Signature, Public Key Encryption||Internet sealed bidding service. We have been providing this to US state transportation agencies since 1998, but only via a native client application, and more recently, an ActiveX browser extension. We would very much like to put this in the web browser.||Sealed bids for performing highway and bridge construction and recently, other kinds of projects.||It must remain sealed until the public bid opening. We accomplish this by having the holder of the decryption key be a separate party from the bid deposit service. Also, strong digital signatures are required for legal reasons.||High-level. I see some value in low-level, but think it should probably be a separate API. Application users need a simple, idiot proof way to encrypt, decrypt, sign, and verify.||Government, Application Developer|
|7/16/2012 11:27:27||Signature, Public Key Encryption, Hash||Developers which will use this API could develop signing applications, avoiding MSCapi and Java.||From a simple XML to a complex PDF, including PAdES, XAdES-XL and a simple PKCS#7 Enveloping.||Becaus document signing is a required step for a REAL e-admin of XXI century. Current alternatives are at last reduced to JAVA.||a standard, cross-browser API||IMHO, a middle option would be great;|
signInit() //specify sign algorithm and return certificate to be used
signAdd() //one call for each item to sign
signFinal() //do the sign
|Academia/Researcher, Government, Application Developer|
|10/15/2012 8:44:09||Signature, MAC, Public Key Encryption, Symmetric Encryption, Hash, eliptical curves, diffie hellman||Developers of web applicaitons. Please see https://github.com/jas-/crypto.js. I have been following the w3c crypto api rfc in anticipation have begun development on a simple interface for native crypto implementations.||XMLHttpRequests for authentication, form submissions etc.||Security in the event of SSL/TLS cipher downgrades, session renegotiation and other unknowns||the speed of native crypto implementation||Low level||Academia/Researcher|