(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.
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.
(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.
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.
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?
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.
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.
> 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.
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.
I believe that this is what projects like Bitmessage are trying to solve. There are a few ways to go about this. One is to give everyone your message. To me, this seems inefficient, since not everyone wants your message. Another option is to use mix networks and distributed hashing, like Tor or Freenet. I suspect that something more useful and efficient could be created using rateless erasure forward error correction codes.
> To me, this seems inefficient, since not everyone wants your message.
I would like to point out BitMessage uses streams. Streams are a collection of nodes that have a particular part of their address in common. If you have an address that is part of one of these streams, your computer will listen into that stream. So you won't download all streams keys and messages, only those that pertain to you.
The NSA keeps encrypted data (e.g. HTTPS traffic) for five years in the event that they might be able to decrypt it later if they need to. This is extremely likely with respect to HTTPS because the keys are owned by the ISPs who can be directed to hand them over, if not today, then at least when their Certs expire and new keys are generated. So HTTPS traffic is effectively as open as plaintext.
Your 4096-bit-encrypted email would probably not be crackable. However, the NSA would know from the metadata that your mails were "of interest" (because they know your correspondent was someone on whom they are trying to build a case) and they can come to you and demand the key, and impose secrecy on you making it a felony if you tell anyone you had surrendered your key.
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.
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.
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.
20 comments
[ 2.8 ms ] story [ 59.8 ms ] thread(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.
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.
(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.
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?
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.
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.
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.
I would like to point out BitMessage uses streams. Streams are a collection of nodes that have a particular part of their address in common. If you have an address that is part of one of these streams, your computer will listen into that stream. So you won't download all streams keys and messages, only those that pertain to you.
Your 4096-bit-encrypted email would probably not be crackable. However, the NSA would know from the metadata that your mails were "of interest" (because they know your correspondent was someone on whom they are trying to build a case) and they can come to you and demand the key, and impose secrecy on you making it a felony if you tell anyone you had surrendered your key.
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.
* 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.