Timeline for Where and how to store private keys in web applications for private messaging with web browsers
Current License: CC BY-SA 3.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 27, 2023 at 14:12 | answer | added | Kote Isaev | timeline score: 0 | |
| Oct 23, 2017 at 18:23 | answer | added | mti2935 | timeline score: 40 | |
| May 23, 2017 at 12:41 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Feb 21, 2017 at 23:28 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jan 22, 2017 at 22:49 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Dec 23, 2016 at 22:44 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| S Nov 23, 2016 at 21:57 | history | suggested | rmalayter |
add key-management tag
|
|
| Nov 23, 2016 at 19:25 | review | Suggested edits | |||
| S Nov 23, 2016 at 21:57 | |||||
| Nov 22, 2016 at 4:46 | history | tweeted | twitter.com/StackCrypto/status/800923501951668224 | ||
| Nov 22, 2016 at 0:15 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Oct 23, 2016 at 0:13 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Sep 22, 2016 at 23:25 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Aug 23, 2016 at 22:57 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jul 24, 2016 at 22:23 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jun 24, 2016 at 21:38 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| May 25, 2016 at 21:31 | vote | accept | CommunityBot | ||
| May 27, 2016 at 12:34 | |||||
| May 25, 2016 at 21:30 | answer | added | user34484 | timeline score: 4 | |
| May 25, 2016 at 20:58 | comment | added | dandavis |
to start a conversation, alice uses ECC to send bob a public key. bob uses the pk to send alice an aes key, which he remembers. now a+b have a shared aes key that no-one else knows. SJCL supports both ecc and aes; github.com/bitwiseshiftleft/sjcl/wiki/Getting-Started, adding --with-ecc to ./configure as the only change, then taking core.js. there's example of both generating ecc and using aes on the sjcl github wiki. it's easier than you might think.
|
|
| May 25, 2016 at 17:09 | comment | added | user34484 | @dandavis i think your idea is very interesting ! How would you achieve this behavior ? | |
| May 25, 2016 at 2:52 | comment | added | dandavis | the safest way to store keys is not to store them at all; use a different key per message derived from a different key per conversation for maximum privacy. | |
| May 23, 2016 at 22:39 | comment | added | SEJPM | @WilliamHird I think what you're talking about is "smart cards". This solution does scale well in controlled environments, but requires the users to invest money in cards and readers (or tokens) which make it unpractical for wider audiences. Also there's no smartcard-access API for browsers AFAICT which means the user would have to install a dedicated application. I'll admit however that this solution can provide very high security. | |
| May 23, 2016 at 21:53 | comment | added | William Hird | @SEJPM Everyone in the loop would have their own chip. Think of it this way. The perfect way to securely store a key that you absolutely had to have remain secure is to memorize the key yourself, of course no human can be expected to memorize long bit strings so the next best thing is a "brain extension": a personal device that stores the information that you always keep with you . ( of course you have to take steps to make sure it cant be stolen). If there is a better solution to this problem, step right up and let's hear it :-) | |
| May 23, 2016 at 21:37 | comment | added | SEJPM | @WilliamHird, who would use the chip (the dev / the admin / the user)? How is he protected against physical data exfiltration? What problems woud this solve? Which would remain? | |
| May 23, 2016 at 21:22 | comment | added | user34484 | @WilliamHird thank you for your answer. This would be a good solution, but I think it is not a feasible solution for application users and a huge impact on usablity. And the problem mentioned by SEJPM with malicious code leaking the key during reading from memory is still present. But thank you I did not thought about "external storage devices" until you mentioned it. | |
| May 23, 2016 at 21:16 | comment | added | user34484 | @SEJPM yes you are absolutely right, if an adversary is able to alter code which is processing the private key during being clear text, all the security is lost. I had some ideas during the last hour, I am going to structure my thoughts and provide some conceptual data model as answer to this question which I would love to discuss with you and other community members. | |
| May 23, 2016 at 21:14 | comment | added | William Hird | Store the private keys on a memory chip and keep the chip in your pocket until you need to use it ??? | |
| May 23, 2016 at 21:08 | comment | added | SEJPM | I think the problem you have to solve before even thinking about encryption is ensuring the code that encrypts is delivered safely. This means that you have to use server-provided code (as you want to minimize user-burden), you have to enforce code validation, you have to ensure the code can't get secrets if your server gets breached and you have to ensure the code can't be tampered. | |
| May 23, 2016 at 20:08 | comment | added | user34484 | @SEJPM Thank you for providing the reference to Mailvelope, I'll have a look at the project. No this should not be a real-time chat, users should be able to communicate with the classic "you have a message in your inbox" procedure. But user messages should never ever get in the wrong hands even if the adversary gets control over the whole system. And thank you I wrote my question with other developers in mind, because finding good introduction points to this topic is more than difficult and maybe we can contribute to other developer projects, with the same problems. | |
| May 23, 2016 at 19:58 | comment | added | user34484 | @SEJPM thank you for welcoming me :) I am getting crazy on thinking about how to solve this problem without creating more system requirements than a browser and https support. I thought about using browser extensions as well but this would not be an acceptable solution for most of my users. Client side JavaScript code must be certified to be not altered as you already mentioned , it is so annoying that achieving good security with standard tools like browsers to protect users privacy is that hard, there should already exist solutions [..] Maybe there is something I have overseen ... ? | |
| May 23, 2016 at 19:23 | comment | added | SEJPM | BTW: Welcome to Cryptography.SE :) And maybe have a look at a somewhat related project: Mailvelope (PGP in the browser with similar problems). And of course: +1 for actually asking "I have a browser and want to do E2E, but how could I?" which looks like it has a large re-usability for other people. And may I also ask: Is this supposed to be real-time only or also "asyn" communication? | |
| May 23, 2016 at 19:22 | comment | added | SEJPM | If you're bound to the browser, there's not really any good and understandable solution for the user. You could use client certificates but I doubt you can use them to encrypt / decrypt stuff outside of the TLS handshake (also the UI for client certificates kinda sucks). The best option you possible have (in terms of security) would be a browser extension (but this would bring other problems). The problem is also how do you get the encryption code to the user? JS? Then you can just keep the keys as well, as you could in Theory just dump the users secret with malicious JS. | |
| May 23, 2016 at 18:41 | review | First posts | |||
| May 23, 2016 at 18:53 | |||||
| May 23, 2016 at 18:38 | history | asked | user34484 | CC BY-SA 3.0 |