
For Privacy and Security, Use Public Keys Everywhere - rosser
http://cacm.acm.org/magazines/2013/9/167144-for-privacy-and-security-use-public-keys-everywhere/fulltext
======
fernly
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.

~~~
zeckalpha
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
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
So then the "email" address can be the public key plus the forum you pull
messages from.

------
malandrew
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.

~~~
m_mueller
(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.

~~~
malandrew
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
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.

------
leke
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
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.

