6 ms·

For Privacy and Security, Use Public Keys Everywhere

30 points by rosser 13y ago

malandrew 13y ago
What is the best way to manage keys considering: (1) Unique keys per service? (2) Easy portability? (3) Syncronization of keys across multiple computers? Or unique keys on each device? (4) Expiry/Rotation of keys (5) Protection of keys such that they are only "usable/unlockable" via password as opposed to being accessible by any person who may sit down at your computer when you're away for five minutes. Etc. Good key management and practices are one of those things that are never really taught anywhere and most people get into managing theirs haphazardly with little consideration of best practices and best protection.
- einhverfr 13y ago
  On top of that good key management is hard. Even in circumstances you totally control (say, databases), there are so many gotchas and so many little things to pay attention to that the chances of ending up with an insecure solution is very high. Now, add to that the problems of exchanging keys over the internet and the fact that this almost always involves some loss of control somewhere. I am not entirely convinced that all these problems are solved once we get into government interference scenarios.
- m_mueller 13y ago
  (1) Dont use unique keys per service, but per service per device you use. Private keys should never be transmitted. They should contain some marker that raises a big warning somewhere in the OS I/O stack if going through. (2) See (1). Don't. Instead, register any new device with a new keypair. Have the user confirm the registration of a new device, using a trusted communication channel (low security requirements: e-mail confirmation, medium: SMS or RSA token handed out to users, high: token coupled with bio-information such as fingerprint scan). (3) See (1) and (2). (4) Well, let them expire, prompt the user to reregister their device according to (2) 1-3 months in advance with increasing frequency. (5) Store the key in an OS controlled keychain that gets locked on device lock. Avoid OSes such as Windows, that still don't offer this feature.
  - hnha 13y ago
    1) how do I read my mail on both my desktop and phone then?
    - m_mueller 13y ago
      Simple, your mailserver encrypts traffic using the public key of the respective device you use to access your mail. To keep things simple, the client could simply send its public key to the server together with the request - if it matches a registered public key for the requested resource, it will be used for encryption.
  - malandrew 13y ago
    If I have specific keys per service device pairs, how do I go about retiring the keys from a device that has been compromised? What if a service doesn't allow you to register multiple keys per account? If I'm using an OS controlled keychain, what is the best way to handle it's contents in a OS agnostic way that is easy to back up just like dotfiles work? Are there any resources that go into how to handle keys safely in a lot more specific detail?
    - m_mueller 13y ago
      The problem about compromised devices is first to recognize it, right? There is basically no way to know for the server, other than a lock request sent by a user using a different, already authenticated device (if that's not available, the user first needs to authenticate a device using the e-mail/sms/rsa token process mentioned above). When such a request is sent, the public key of the compromised device stored on the server gets deauthorized. In fact, a per-device public keys makes the whole process much easier, obviously, since specific devices can be locked out, rather than locking a whole user account. About OS keychains: I'd imagine there are some multi-platform wrapper libraries to deal with this, but I've never specifically looked for such a thing, sorry. If there isn't already such a library in place I'll probably write one in javascript in 2014, since we're going to need it for the PaaS we're currently developing.
fernly 13y ago
This is encryption that accomplishes nearly nothing. Your email messages themselves may be encrypted but the addresses and other metadata -- who you converse with, when, and how often -- is completely open. If you exchange mail with a person B, who exchanges mail with a person C, who exchanges mail with a person T that is the subject of a "terrorism" investigation, your mail will be collected and, whether encrypted or not, the fact that you are thus "implicated" will be noted. Indeed the fact that you are "hiding" your email will increase the level of interest in you. In addition, email encryption does nothing to protect your text messages, web browsing, ftp transfers, skype calls etc.
- gyepi 13y ago
  > This is encryption that accomplishes nearly nothing. I disagree. Encryption, done correctly, maintains the secrecy of the message. > Your email messages themselves may be encrypted but the addresses and other metadata -- who you converse with, when, and how often -- is completely open. Absolutely true, but this is a secondary issue that requires a combination of technical and political solutions. > In addition, email encryption does nothing to protect your text messages, web browsing, ftp transfers, skype calls etc. Right. But there are other solutions to these problems. Security requires a layered approach. There's no way to protect all communications with a single solution, given our current systems.
- zeckalpha 13y ago
  Forget the email model of public metadata. What about a new protocol where you encrypt your message and its metadata completely, and give it to everyone (for some N). The "address" is just the public key used to encrypt it.
  - ketralnis 13y ago
    For a small number of messages, maybe. For the number of email messages exchanged daily on the internet? Probably not. For voice calls? Certainly not.
    - DennisP 13y ago
leke 13y ago
Isn't public/private key encryption just for transferral of non-plaintext passwords, used later by other cyphers like AES? This article seems to suggest to use it as a method of encrypting plain text communication.
- raimue 13y ago
  In general, public/private keys can be used for the encryption itself. However, if you want to send a document to multiple recipients you would need to encrypt the whole plain text multiple times with each public key. However, asymmetric crypto requires much more resources than symmetric crypto, as the latter is basically a XOR operation only. Therefore, in implementations such as OpenPGP/PGP, a new random symmetric key is generated with which the plain text will be encrypted, for example using AES as you suggested. Afterwards, this symmetric key will be encrypted with the public key of the recipient and attached to the cipher text. When sending a document to multiple recipients, you only need to encrypt the symmetric key multiple times. The symmetric key is usually short compared to the rest of the document. So if you are only encrypting for a single recipient you could encrypt using the public key directly. However, it would still need more computing power. This might be negligible on modern Desktop computers with lots of computing power and even hardware crypto support, but for embedded devices such as your smartphone it's still an important factor. PS: Of course, there is more to OpenPGP/PGP such as the Web of Trust and digital signatures for verification of the sender of a document.
dgroves 13y ago
This sounds simple enough, however - we have two giant issues: * Identity management * Key management And for each we need many-to-many mappings with a full life cycle management including key/identity rotation, revocation and destruction and of course the resulting key storage problem. I am likely more "paranoid" that you; I have over 600 keys randomly generated (normally 80 characters long unless a service can not meet my security requirements and then I dumb it down 1 char at a time until it is accepted.). I can not possibly recall any of them by memory. Each key is encrypted with a one time pad, and I secure them with two factor authentication in order to store them on my USB drive; which I wear on my neck... It took special effort for me to post this. :/ I change keys regularly. I keep data about each key such as the dates in order to age them, and change them on a regular basis. And they are always randomly generated with a Mersenne Twister. It is actually not paranoid, and it is ridiculous. For all of this effort; I can at best say that my password was not the reason your company was compromised and my personal data shit all over the internet. Given that most companies sell the fuck out of that data anyhow it is completely unprotected. Second given the number of databases opened up by the skeleton key of SQL injection - my password is not the lowest hanging fruit. Of course this doesn't protect against rubber hose cryptanalysis. Today of course they will taze your balls, not break your legs... So you are going to give up your keys, but not before you have been hurt like you never ever hurt in your life, so get over it. So what I am doing is not security, this is actually just best practices of key and identity management. Few people do what I do; and I have articulated why it is still not secure (rubber hose) and hopefully it is clear why we desperately require better solutions. Everybody should be doing what I do at a minimum.

30 points by rosser 13y ago

What is the best way to manage keys considering: (1) Unique keys per service? (2) Easy portability? (3) Syncronization of keys across multiple computers? Or unique keys on each device? (4) Expiry/Rotation of keys (5) Protection of keys such that they are only "usable/unlockable" via password as opposed to being accessible by any person who may sit down at your computer when you're away for five minutes. Etc. Good key management and practices are one of those things that are never really taught anywhere and most people get into managing theirs haphazardly with little consideration of best practices and best protection.

einhverfr 13y ago
On top of that good key management is hard. Even in circumstances you totally control (say, databases), there are so many gotchas and so many little things to pay attention to that the chances of ending up with an insecure solution is very high. Now, add to that the problems of exchanging keys over the internet and the fact that this almost always involves some loss of control somewhere. I am not entirely convinced that all these problems are solved once we get into government interference scenarios.
m_mueller 13y ago
(1) Dont use unique keys per service, but per service per device you use. Private keys should never be transmitted. They should contain some marker that raises a big warning somewhere in the OS I/O stack if going through. (2) See (1). Don't. Instead, register any new device with a new keypair. Have the user confirm the registration of a new device, using a trusted communication channel (low security requirements: e-mail confirmation, medium: SMS or RSA token handed out to users, high: token coupled with bio-information such as fingerprint scan). (3) See (1) and (2). (4) Well, let them expire, prompt the user to reregister their device according to (2) 1-3 months in advance with increasing frequency. (5) Store the key in an OS controlled keychain that gets locked on device lock. Avoid OSes such as Windows, that still don't offer this feature.
- hnha 13y ago
  1) how do I read my mail on both my desktop and phone then?
  - m_mueller 13y ago
    Simple, your mailserver encrypts traffic using the public key of the respective device you use to access your mail. To keep things simple, the client could simply send its public key to the server together with the request - if it matches a registered public key for the requested resource, it will be used for encryption.
- malandrew 13y ago
  If I have specific keys per service device pairs, how do I go about retiring the keys from a device that has been compromised? What if a service doesn't allow you to register multiple keys per account? If I'm using an OS controlled keychain, what is the best way to handle it's contents in a OS agnostic way that is easy to back up just like dotfiles work? Are there any resources that go into how to handle keys safely in a lot more specific detail?
  - m_mueller 13y ago
    The problem about compromised devices is first to recognize it, right? There is basically no way to know for the server, other than a lock request sent by a user using a different, already authenticated device (if that's not available, the user first needs to authenticate a device using the e-mail/sms/rsa token process mentioned above). When such a request is sent, the public key of the compromised device stored on the server gets deauthorized. In fact, a per-device public keys makes the whole process much easier, obviously, since specific devices can be locked out, rather than locking a whole user account. About OS keychains: I'd imagine there are some multi-platform wrapper libraries to deal with this, but I've never specifically looked for such a thing, sorry. If there isn't already such a library in place I'll probably write one in javascript in 2014, since we're going to need it for the PaaS we're currently developing.

fernly 13y ago

This is encryption that accomplishes nearly nothing. Your email messages themselves may be encrypted but the addresses and other metadata -- who you converse with, when, and how often -- is completely open. If you exchange mail with a person B, who exchanges mail with a person C, who exchanges mail with a person T that is the subject of a "terrorism" investigation, your mail will be collected and, whether encrypted or not, the fact that you are thus "implicated" will be noted. Indeed the fact that you are "hiding" your email will increase the level of interest in you. In addition, email encryption does nothing to protect your text messages, web browsing, ftp transfers, skype calls etc.

gyepi 13y ago
> This is encryption that accomplishes nearly nothing. I disagree. Encryption, done correctly, maintains the secrecy of the message. > Your email messages themselves may be encrypted but the addresses and other metadata -- who you converse with, when, and how often -- is completely open. Absolutely true, but this is a secondary issue that requires a combination of technical and political solutions. > In addition, email encryption does nothing to protect your text messages, web browsing, ftp transfers, skype calls etc. Right. But there are other solutions to these problems. Security requires a layered approach. There's no way to protect all communications with a single solution, given our current systems.
zeckalpha 13y ago
Forget the email model of public metadata. What about a new protocol where you encrypt your message and its metadata completely, and give it to everyone (for some N). The "address" is just the public key used to encrypt it.
- ketralnis 13y ago
  For a small number of messages, maybe. For the number of email messages exchanged daily on the internet? Probably not. For voice calls? Certainly not.
  - DennisP 13y ago

leke 13y ago

Isn't public/private key encryption just for transferral of non-plaintext passwords, used later by other cyphers like AES? This article seems to suggest to use it as a method of encrypting plain text communication.

raimue 13y ago
In general, public/private keys can be used for the encryption itself. However, if you want to send a document to multiple recipients you would need to encrypt the whole plain text multiple times with each public key. However, asymmetric crypto requires much more resources than symmetric crypto, as the latter is basically a XOR operation only. Therefore, in implementations such as OpenPGP/PGP, a new random symmetric key is generated with which the plain text will be encrypted, for example using AES as you suggested. Afterwards, this symmetric key will be encrypted with the public key of the recipient and attached to the cipher text. When sending a document to multiple recipients, you only need to encrypt the symmetric key multiple times. The symmetric key is usually short compared to the rest of the document. So if you are only encrypting for a single recipient you could encrypt using the public key directly. However, it would still need more computing power. This might be negligible on modern Desktop computers with lots of computing power and even hardware crypto support, but for embedded devices such as your smartphone it's still an important factor. PS: Of course, there is more to OpenPGP/PGP such as the Web of Trust and digital signatures for verification of the sender of a document.

dgroves 13y ago

This sounds simple enough, however - we have two giant issues: * Identity management * Key management And for each we need many-to-many mappings with a full life cycle management including key/identity rotation, revocation and destruction and of course the resulting key storage problem. I am likely more "paranoid" that you; I have over 600 keys randomly generated (normally 80 characters long unless a service can not meet my security requirements and then I dumb it down 1 char at a time until it is accepted.). I can not possibly recall any of them by memory. Each key is encrypted with a one time pad, and I secure them with two factor authentication in order to store them on my USB drive; which I wear on my neck... It took special effort for me to post this. :/ I change keys regularly. I keep data about each key such as the dates in order to age them, and change them on a regular basis. And they are always randomly generated with a Mersenne Twister. It is actually not paranoid, and it is ridiculous. For all of this effort; I can at best say that my password was not the reason your company was compromised and my personal data shit all over the internet. Given that most companies sell the fuck out of that data anyhow it is completely unprotected. Second given the number of databases opened up by the skeleton key of SQL injection - my password is not the lowest hanging fruit. Of course this doesn't protect against rubber hose cryptanalysis. Today of course they will taze your balls, not break your legs... So you are going to give up your keys, but not before you have been hurt like you never ever hurt in your life, so get over it. So what I am doing is not security, this is actually just best practices of key and identity management. Few people do what I do; and I have articulated why it is still not secure (rubber hose) and hopefully it is clear why we desperately require better solutions. Everybody should be doing what I do at a minimum.