Great article.
We are in the same boat as u and struggling to see how it can be achieved and if it is worth doing over and above just using Https to transport the sensitive data.
U mention 'I learned quickly that asymmetric key pairs are (usually) used to encrypt symmetric keys and a symmetric key is used to encrypt the data.' have u any info/references for this 'best practise'?
Did u actually end up with a viable production quality solution?
Thanks for your time.
Regards
John
I don't have a best practice reference. It might have been mentioned here schneier.com/books/applied_cryptog... but I only read about a third of that book back in 1998. If I recall, I asked a very experience dev how it was done and he mentioned it was done that way (the guy I asked used to work on a S/MIME toolkit back in the day).
My solution worked when I tested it but it never actually shipped. The company I worked for folded (for other reasons!) before it was deployed.
The reason that you only typically use the asymmetric pair to encrypt/decrypt a symmetric key is that asymmetric keys are very large, CPU intensive, and fairly slow. If you're only encrypting relatively small messages at a fairly slow rate, or large messages at a VERY slow rate, it's ok to just use the asymmetric keys. This is how PGP works, for example.
For just getting data to the server there is no reason whatsoever to use Web Crypto as the same algorithms are used to transfer data.
The typical reason to use Web Crypto is this flow:
Client (Encrypt)
Server (Can't read)
Client (Decrypt)
Some of the more obvious examples of companies that would use this are ones like Dropbox and 1Password, but potentially anywhere sensitive data is kept might be the case for client->client crypto.
For example if a law firm uses an online document editor, it would be a huge risk both to the law firm and to the company hosting their documents if they stored unencrypted blobs on the server.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article.
We are in the same boat as u and struggling to see how it can be achieved and if it is worth doing over and above just using Https to transport the sensitive data.
U mention 'I learned quickly that asymmetric key pairs are (usually) used to encrypt symmetric keys and a symmetric key is used to encrypt the data.' have u any info/references for this 'best practise'?
Did u actually end up with a viable production quality solution?
Thanks for your time.
Regards
John
I don't have a best practice reference. It might have been mentioned here schneier.com/books/applied_cryptog... but I only read about a third of that book back in 1998. If I recall, I asked a very experience dev how it was done and he mentioned it was done that way (the guy I asked used to work on a S/MIME toolkit back in the day).
My solution worked when I tested it but it never actually shipped. The company I worked for folded (for other reasons!) before it was deployed.
Thanks for the prompt response and the great article.
The reason that you only typically use the asymmetric pair to encrypt/decrypt a symmetric key is that asymmetric keys are very large, CPU intensive, and fairly slow. If you're only encrypting relatively small messages at a fairly slow rate, or large messages at a VERY slow rate, it's ok to just use the asymmetric keys. This is how PGP works, for example.
Thanks for the info
For just getting data to the server there is no reason whatsoever to use Web Crypto as the same algorithms are used to transfer data.
The typical reason to use Web Crypto is this flow:
Some of the more obvious examples of companies that would use this are ones like Dropbox and 1Password, but potentially anywhere sensitive data is kept might be the case for client->client crypto.
For example if a law firm uses an online document editor, it would be a huge risk both to the law firm and to the company hosting their documents if they stored unencrypted blobs on the server.