Mobile - Using PGP on a mobile device can be risky, as it requires storing the private key on devices that are likely to have known security issues. Many people recommend against it, as it puts the private key at too much risk.
ARGH. The whole point of PGP keyrings --- the costliest part of the PGP UX --- is that you don't have to have a single key. If you're terrified of exposing your secret key on your mobile device (which is frankly the most secure device you own), just cut a new key for it.
Any time someone suggests a new application for PGP, people come out of the woodwork saying things like "what, you want me to put my PGP key in my browser?" No. We want you to put --> a <-- PGP key there.
> If you're terrified of exposing your secret key on your mobile device (which is frankly the most secure device you own), just cut a new key for it.
The mobile device is the one most people have the least control over in terms of software (which can be both good and bad) but is also the one they are most likely to lose in a shady part of town.
Really? That's not how I treat my security at all. My phone seems to clearly be the least secure computer I own. Admittedly I run all linux on my non-phone computers, but I'm not totally sure I'd agree with you even if I ran Windows or OSX.
If it's an iPhone, then yes, it is far and away the most secure device you own. Everything is encrypted all the time through an HSM which will perform decryption only if given the device PIN. The key is never in memory and any attempt to extract it from the HSM will result in its self-destruction. It is impossible to recover data from the phone without the PIN. You can only erase the device and restore from a backup. While the device can be lost, the only threat is that a thief will erase and resell it. With iOS 7 and Find My iPhone turned on, even that is not possible. An attacker would not get your data in any case.
This is orders of magnitude safer than a full-disk-encrypted laptop because people hardly ever shut down their laptops, so keys remain in memory. There is also the possibility of cold-boot attacks, and of course the (retrospectively) insane design wherein any program you run can access all of your data.
iOS applications are always code-signed in a way that is tied to a real person or corporation, thoroughly sandboxed, and subject to review, making malware essentially non-existent. If discovered, it can be yanked at any time. What few remote exploits there have been were national news - and quickly resolved.
iMessage is end-to-end encrypted 100% of the time using a keybag - each device on your iCloud account has its own private key that never leaves the device. You get notified when a key is added to the keybag. This is really incredible, because without even knowing it, huge swaths of the population are using properly end-to-end encrypted messaging just by owning iPhones.
iOS is a tight ship and its attack surface is minuscule compared to that of a commodity computer.
Ah, that makes a lot of sense. If you are discounting Apple themselves (and people using social engineering techniques to gain access to Apples backdoors) and the large list of States and Corporate actors who have access as potential attackers then you are absolutely correct.
I didn't know about keybag, that's very interesting.
Ah, I was unclear. I meant the Governmental to private intelligence contractors path, not Apple selling data to data brokers or something like that - that seems very unlikely.
Where do I read more about this - it sounds fantastic and yet I just assume "proprietary = lazily implemented and they can read my keys cos it's on their server"
There was a talk at passwords^10 (2010) about security of pins/keys in iphone/android/windows phone (IIRC). Don't recall who the speaker was, and all the links to talks/programs etc have gone to bitrot (might be possible to find on archive.org, I've yet to try that).
If I remember correctly an encrypted iphone (4 I guess?) was the most secure, but with a bit of hackery one could use the device itself to bruteforce the pin (and thus access the key, and then the data). Not sure if that's actually been patched in later iterations of the iphone.
If you find this stuff interesting, consider going to passwords^14 (August 5th-6th, Las Vegas): https://passwordscon.org/
You have to be more specific: Secure from what kind of threat? There are many threats ranging from service providers deciding to uninstall "unpopular" applications that threaten antiquated revenue models to State threats used against activists and dissidents.
Yeah, I have mixed feelings about that one; I almost didn't include it, but it's an argument that I hear often enough that I thought it was worth pointing out.
Personally, I have my key on my phone, and I'm fairly comfortable with it - though there are certainly some that aren't.
But, wouldn't that mean that if you share the same email account on your Desktop and Phone, that using a different key on your phone would mean you could not decrypt emails intended for your Desktop?
My understanding was that you can associate a key with your email address, does this just mean you would have two keys associated, one for "me@me.com Desktop" and one for "me@me.com Phone"?
While the spirit is laudable—I'm not sure if there's an 'e-mail security' version of https://craphound.com/spamsolutions.txt, but, if there were, then I'm pretty sure that one of the reasons for failure would be "You are a private individual announcing that you will be rolling out a new standard for e-mail in a couple of weeks".
Change has to start somewhere. Starting with a draft and getting feedback from the community before pushing it ahead for more formal standardization seems like the right place to me.
As I said in the article, my goal is to get people talking about potential solutions. I have little hope that the solution I propose will be accepted and used as is - but if it gets more people talking, and discussions going about something that will work, then it was worth the effort.
> Change has to start somewhere. Starting with a draft and getting feedback from the community before pushing it ahead for more formal standardization seems like the right place to me.
I agree that change has to start somewhere, and, to be clear, I don't mean anything against you, but rather against the likelihood of any success: I think that we're stuck with a broken legacy system until something radical, by which I mean "all existing infrastructure is destroyed"-type radical, forces a ground-up re-start.
Nonetheless, there seem to be at least two competing objections to trying to start the change here:
- My point of view: It seems unlikely that the eventual solution (if there is one) will come from a large group carrying a large and representative collective weight, not an individual (or even a small, self-selecting community like HN, or—probably, and with no offence meant—the readership of your blog) with a necessarily specialised viewpoint; and that a large group is more likely to buy in to "let's create a new standard!" than "let's use my / my community's standard that I / we created without your viewpoints or input!"
- Alternatively, if one believes (as it seems you do) that the solution will start with an individual, then surely the thing to do is to deliver a product, not a promise. I don't know about anyone else, but my reaction when I see assurances of delivery RSN is automatic scepticism.
Ok, I'll bite. This is a good post - I am negative on your ability to pull this off, but it's a worthwhile discussion to have IMO
* Totally anonymous (ie no metadata trail) communication seems impossible / impractical. If everywhere is the Tor then we massively increase traffic, (not to mention the trustworthiness of "everyone" is a lot lower per unit than everyone currently running a tor node)
Anyway, even if a encrypted anonymous message arrives for me, just working out who it's from without any metadata seems complex web of double decryption
I do struggle with how anonymity is going to solve all problems with totalitarian states. In the end we need to solve this in the real world of politics and execution squads so we don't mortally worry about letters or emails being read.
* there is a lot more here than my tired brain can handle - but my main concern is a simple human one
- if secure anonymous comms is "impossible", then I could see levels of secure encryption (sent from my iPhone, sent from my PC hardwired at home that has a secure USB boot on my key ring). But this idea demands that as the recipient I work hard to determine from context if the message is secure - aha it's 11pm in the UK and Adam just mailed me a secure note saying we should give everyone an Owl. Chances are high he is pissed and his mates sent it.
Once technology stops helping us make those decisions it's kind of pointless - May as well just keep sending clear text is not an irrational stance.
Be interested in the discussion in the morning - cheers
* lastly - what email client do you guys use that allows gpg on mobile?!
I'm not the only one working on it, but I am the lead. I have my doubts too - but I don't see that as an issue. Any email replacement has a long way to go before it would be used widely - getting a real standard through the IETF alone will be difficult. But, this is a starting point - it's something to build from, a conversation starter if nothing else. Even if it gets ripped to shreds, if it gets people actively working on another solution, then it was worth it.
It's the conversion that matters to me, there needs to be a solution to this, and for that to happen people need to get engaged.
As for anonymity, I don't think there's a good option there - the spec I'm writing isn't anonymous to the recipient, or to the recipient's server. My focus is on encryption and authentication. There's more metadata exposed than I'd like in my model, but it's a balancing act between competing goals. We'll see that in any standard that replaces email - there are many forces at play with different goals and different requirements. No solution will make everyone happy.
There are issues, metadata being a big one, that the proposal I'm working one doesn't address as well as I'd like. I'm hoping others will try to tackle this issue as well, and come up with other methods that may work better.
When we are ready to release a public draft, it'll just be the first step. We don't expect anyone to just say "Hey, that's perfect, let's replace all the email servers" - that isn't going to happen, and it's not our goal. A lot of review will be needed, changes will need to be made to address different concerns, and maybe it'll progress to a useful system. Maybe somebody else will come along with a different idea, and that one will get the community backing. What I want is a replacement system that is secure - I don't care who's design it is. It's not about ego, not about winning for me - it's about prodding the community into action.
As to the last question, as others have answered, K-9 Mail. It works well enough for my needs.
> Totally anonymous (ie no metadata trail) communication seems impossible / impractical. If everywhere is the Tor then we massively increase traffic
That really isn't the problem. If onion routing works for anything it works for email. Text is low bandwidth. You make the email servers relay for each other so it scales: More email servers, more relays. And if you're willing to have your emails delayed by e.g. half an hour you can get a much stronger level of anonymity than you can with realtime systems like Tor because random delays between hops on high traffic nodes in combination with padding to power-of-two size boundaries makes traffic analysis extremely difficult.
> Anyway, even if a encrypted anonymous message arrives for me, just working out who it's from without any metadata seems complex web of double decryption
Every message to you should be encrypted against your public key, so you decrypt it with your private key and immediately learn who it's from. The issue is if you have multiple public keys and you don't want the message to identify which one to use in any way. There could be some interesting cryptographic solutions to that I'm not aware of, although in the worst case you could just try all of them until one works.
I went off on one thinking how do I find which public key
Of my 4000 contacts is the right one ... When no-one will encrypt a secret message with their own private key !
Sorry - total brain fart. Apologies to others down thread too.
Anyway, even if a encrypted anonymous message arrives for me, just working out who it's from without any metadata seems complex web of double decryption
It's simple. You can encrypt everything, including the metadata. Then, when it arrives in your box, you simply decrypt everything, and see who it's from. It doesn't have to be anonymous.
How do I know which key to use to decrypt it? If there is any identifier then that is an identifier for the sender - an irrevocable one that will slowly build up a metadata trail.
Anonymity is hard if not impossible - it's why I don't think evoting can work and why this seems laudable but hard
Your software can try each key until one of them works. If none of them work, it can say "this message can't be opened with one of the keys available". Or even "this message requires key 1234 5678 to open, but it's not currently available". It's not something you need to care about.
You don't need to have any information about the sender unencrypted. It's not at all necessary to deliver the message.
Hmm - I get an average of 1000 messages a day, mostly spam, and I have - good grief - 4000 seperate email addresses in my inbox - and it just took 0.001 s to decode a txt file
FYI, bitmessage (https://bitmessage.org/) is a working implementation of this "Everyone Gets Everything" model. Maybe have a look at how they do things ?
K-9 Mail is good, but it doesn't support PGP/MIME. Only inline PGP. Doesn't look like they will either as it's been on their todo list for several years now with no progress.
Whilst this is true it is not really that big a problem. You can open the attachment, copy to the clipboard and then use APG to decrypt. It could be nicer and would be excellent if the client supported PGP/MIME, but I can live with it.
I would say it's a not-insurmountable problem, but definitely a big problem. If I have to copy-and-paste all my e-mails into APG just to read them, that's a significant inconvenience.
The title "The Sinking Ship of E-Mail Security" implies there once was security but there never really was. For the most part, email is more like a postcard than a sealed letter.
From a quick look around, it looks like the best bet on asynchronous forward secrecy that doesn't rely on a (highly) trusted server (one that eg: shares a secret with every sender and receiver, kerberos-style) is something along the lines of "The Text Secure Protocol"[1].
No reason why this couldn't be bolted on top of email (send the actual message as an attachment like with pgp/mime). It would probably create a new set of metadata (requests to the recipients "half-key" service/server (locating which could be delegated to SRV records or something similar, with domain derived from the email address) -- but I'm not aware of any other schemes for generating ephemeral keys in a reasonable manner compatible with (semi)asynchronous communications.
It does seem like "true" off-line message composition wouldn't be possible (the email client (or client service) needs to go online in order to encrypt/pack up the final message. This means that drafts/messages "in transit" would be possible to recover from the senders device in the case of eg: several mails being written on a flight w/o net access, and a search/seizure before mails could be encrypted to the receiver).
All in all, this sounds like a tricky problem... Anyone know of any recent bright ideas in the field of PFS for asynchronous messaging?
This has really got me thinking about an architecture I had not really considered before so forgive the obvious in this - it's partly aide memoire and partly a contribution to OP
- goals of the "new email" should presumably be to reduce the ability of state actors and major comms providers to collect sufficient metadata to conduct mass surveillance for tyranny or profit.
as such we can try either
- Vast citizen owned mesh networks (ie every smartphone is a ISP)
- Anonymity over traditional large ISPs / backbones
Anonymity is hard. We could encrypt entire message and then round robin decrypt each incoming message, this would cripple all metadata apart from the TO: field and mean any listener would need to own most entry points to catch the first uptake. It seems difficult - webs of trust, guessing the encryption key.
Add in other constraints - all messages in transit and at rest are encrypted - gmail becomes no more than S3 - and we see the end of free email, and weirdly a return to POP3 as the client must store all my mail.
If this does exist however, why restrict it to emails - every message format seems similar - MQ and Facebook can all go this way.
Mesh networks have even greater barriers to uptake ...
I've thought a lot about this and so far the solutions I've seen put forth (e.g. Flowingmail, Bitmessage, for starters) don't seem likely to get any widespread adoption, and that can be the death knell of anything like this that relies on network effects. Hell, I can't even get people to send me a PGP key even when I refuse to send them important documents without one (they just say they're going to send me one later, then forget about ever getting the document they wanted). It's really not that hard to generate a PGP key, but even motivated people don't do it.
My immediate intuitions are that 1.) this is a very hard problem to solve and 2.) if it's going to be solved in any reasonable amount of time, it needs to be bootstrapped into existing, popular methods of communication (such as e-mail). Adding some sort of PKI into the existing e-mail spec would probably be a good start, since it's just not something that people are used to dealing with.
I think of email like a postcard. It's addressed to me, but anyone can read it if they snoop in my mailbox. I don't expect it to be really secure, and I don't do anything that requires real security via email. Simple enough.
what arrives in your inbox is often out of your control. account confirmation and password reset emails, pictures/info others send you who are more satisfied that you with the level of privacy normal email provides, etc.
Email security is really bad. We have a lot of companies trying to roll out "secure email" every week.
There are a ton of problems to solve before one of these actually works, javascript crypto being the least (since HN likes to discuss it...). Backwards compatibility with old email protocols and insecure service is clearly a weak-link in any hypothetically secure service.
It would be nice to see a more distributed protocol...where the bulk of the world's email is holed up in a few company's data centers.
I am always scared that if I start signing my emails (the least I can do) they might start looking weird to my friends, family, and colleagues. They may even think that the block of gibberish may be spam. I do like my KDE KMail client which masks the signing information and presents signed and unsigned messages in a sane way.
I would suggest taking a look at I2P-Bote. Although I haven't had it installed for a year at least, I2P-bote seems to be a slow-moving project, with lots of features TBD, but it does hit all the keywords.
ARGH. The whole point of PGP keyrings --- the costliest part of the PGP UX --- is that you don't have to have a single key. If you're terrified of exposing your secret key on your mobile device (which is frankly the most secure device you own), just cut a new key for it.
Any time someone suggests a new application for PGP, people come out of the woodwork saying things like "what, you want me to put my PGP key in my browser?" No. We want you to put --> a <-- PGP key there.