Encryption use-case. Re: Last call for Use-cases/Goals for web crypto charter

IMHO, key backup must be an intrinsic feature of a message based
encryption system.  This is probably why message based encryption
haven't made it in the consumer space; it is really messy.

"cloud-sync" or whatever the proper terms is then becomes more or
less required as a lighter alternative to explicit key backup.

In the end just about everything boils down to strong authentication
to a few trusted providers which is why I desperately cling to that topic :-)

Anders

On 2011-11-25 17:14, David Dahl wrote:
> +1
> 
> Plus, I can imagine all kinds of messaging apps: Real time chat, twitter-like broadcast apps, etc.
> 
> More use cases:
> 
> 1. Via the file API, encrypt files before transferring to cloud storage.
> 
> 2. LocalStorage encryption
> 
> 
> Regards,
> 
> David
> 
> ----- Original Message -----
> From: "Andrew Sutherland" <asutherland@asutherland.org>
> To: public-identity@w3.org
> Sent: Thursday, November 24, 2011 3:08:45 PM
> Subject: Re: Last call for Use-cases/Goals for web crypto charter
> 
> On 11/24/2011 05:55 AM, Harry Halpin wrote:
>> So everyone who has a use-case please send it now, described in 1-2 
>> sentences. Then also, *look* at the primary/secondary/ and 
>> out-of-scope features and list what features are necessary for the 
>> goal. Also, to see if anything is missing.
> 
> Use-case: Encrypted messaging client.
> 
> Primary necessities: key pair generation, encryption, decryption, 
> digital signature generation and verification, hash/message digest 
> algorithms, key storage.
> Secondary necessities: strong random number generation, destruction of 
> temporary credentials
> 
> Primary not required: key transport/agreement algorithms
> 
> 
> Additional details: Mozilla Labs has an encrypted messaging experiment 
> under development, deuxdrop. ( https://github.com/mozilla/deuxdrop).  
> While user trust of the client's code is more biased towards an 
> extension model for deployment, we are trying to use as many web 
> technologies as possible and to be capable of operating without any 
> special privileges in a standard web browser.  Right now, crypto is 
> provided by the NaCl library ( http://nacl.cr.yp.to/) exposed to JS via 
> privileged js-ctypes shims, but if we could use baked-in web platform 
> crypto like DOMCrypto or the outcome of the web crypto effort, that 
> would be much better.  Obviously, the underlying crypto primitives would 
> need to change, as I don't expect NaCl's primitives to be adopted, but 
> our current implementation was never intended to be permanent.
> 
> Andrew
> 
> 
> 
>

Received on Friday, 25 November 2011 17:36:44 UTC