Creepiest thing with seeing this ticket (again?) is noticing that the first comment is about that is used to be illegal to write anything with cryptographic security in the US and sell/give it to the outside world.
Any signatory to the Wassenaar Arrangement, which includes the entirety of North America, Europe (including Russia), Australia, India, and Pacific Asia (minus China) must consider cryptographic technologies to be munitions for the purposes of export. Now, these restrictions have been considerably loosened to the point that the export isn't really controlled, but international law still considers it a munition. The US is hardly unique in this regard.
It works the other way too. A surprising number of countries still restrict the import of cryptographic technology, including several EU states.
This is still in place, just now regulated[0] rather than outright illegal.
Particularly noticeable during the iOS app store[1] submission process (Android's is somewhat more lax[2] leaving the liability firmly with individual developers)
That's why there were those "illegal" t-shirts with the RSA algorithm printed out in Perl.
But I have a more pragmatic approach. If nuclear launch codes were written out on t-shirts I wouldn't be happy about it either. I think the real problem is ignorance. The US's main role after 1945, and the role of the UN, was and is to prevent another world war. Whether by virtue or by ignorance they have been successful, with the notable exception of a partial world war in the Middle East.
Having said that, the problem is ignorance towards technology and knowledge and resentment towards talent or individual ability. It's more general fear towards things they cannot understand, or rather, things they understand that they cannot subvert. But, I don't like to reduce myself to a protagonist's syndrome and I can more or less understand why the US government does what they do.
The only real node of certainty in the whole equation is that individual freedom is where the line should be drawn. And unfortunately for the obnoxious prescriptive types, any human can invent cryptography on their own whilst living in a cave.
I remember back in the 90s exchanging PGP keys with my roommate to exchange encrypted emails. It was supposed to be so easy. Just 12 simple steps. Every time.
at least you had a friend to email! I couldn't get any of my friends to do it. "Man we can encrypt our emails." "But why..." "It'd be cool" "This seems hard." "Come on, exchange keys with me." "I don't want to make one."
PGPs trust levels are what made PGP never take off: even laypersons could see this is theater, not security.
For reasons unclear to me Thunderbird chose not to go with something like autocrypt.org, but stick with standard PGP and implement parts of their attempt to simplify, which isn't nearly enough to get regular users on board, never mind implement things like forward security, which autocrypt does.
A missed chance from Mozilla, secure email would fit in well with their mission.
Better to use a protocol designed with encryption in mind, like Signal, to get forward secrecy, avoid leaking metadata, and have encryption always on by default.
UPDATE: I have been reminded that PGP does not have to be used with email. I meant to say that I used to love using PGP with email, since that is the primary way I have used it. I will not comment on the use of PGP outside of email, since I haven't carefully examined its use in other contexts.
That is the single most common misconception around PGP, and it comes up every time:
(Open)PGP is first and foremost a flexible packet format (and other specs), and GnuPG is more of a CLI "library" to interface with it -- all of it. You can build something that hides metadata, you can have forward secrecy, and encryption always-on by default with PGP (and GnuPG). You can use it for whatever trust model you want, neither OpenPGP (the specs) nor GnuPG prescribe a certain model. It provides building blocks. It just happens that no good client exists and no more high level specs were written that use it, which is highly unfortunate. The client in this case here used to be "Enigmail" (a wrapper around GnuPG), and now is built-in since plugins are not allowed to be as powerful with the new browser architecture that Thunderbird piggybacks on and this was the only way to bring PGP to Thunderbird users. Also, there are some more modern libraries nowadays for standard use cases around PGP.
Signal was able to move faster since it did not exist, did not try to build things in an open and collaborative fashion, still refuses to work in any open way. Its founder Moxie even openly argues against standards [x]. I am not saying he does not have "a point", but in the long run this will lead to just more silos and ultimately technical stagnation, and for me goes against the ethos of "a public and open inter-net." (and the learnings behind it. 'Those who cannot remember the past are condemned to repeat it.')
That said, I do agree with your comment on a pure end-user level. It still makes me sad to always see this confused and not acknowledged better in places like HN, where people "should know". Technologists can defend and strive for the most promising long-term solution and "proper way to do it", and at the same time recommend "the best of the bad that is currently available". Even if it is confusing sometimes.
Just to give an example, there are plenty of high security use cases that require using smartcards. I'm very grateful that the OpenPGP standard and GnuPG exist that (can be made to) work in such cases. Signal does nothing in that space, rightfully so. But you are comparing different fruit to each other, which is kind of unfair.
[x] and still calls himself an "anarchist". You would think those know better...
Signal is great as an all in one solution if encrypted messaging is a hobby. It is also very good for mobile and encrypted occasional messages.
If you try to actually build a secure environment within a group that tries to maximize security while getting real work done you find you want to be encrypted by default at least with each other. Signal is pretty suboptimal for heavy volumes of messages. If you and I have three threads going they are all jumbled together. If I want to send to more than one person I have to whip out my phone and form a group and name it.
PGP is imperfect but with the right settings and defaults it is far better than having email default to clear text. And in any long term endeavor with more than a few people you will find you want email.
Signal is great for what it does. It is not designed to be a high volume working tool like email though.
Your article seems to focus on individuals. Consider also organisations.
Transport-level security and authentication of email content is a perfectly valid use-case for an organisation when protection against third-party interference is desired. They don't need to worry about forward secrecy, they just need attachments to be transmitted in a legally-compliant manner.
For example each month HR email me my payslip as an encrypted attachment. I decrypt it and save locally. They just have a batch job that encrypts for each user and sends. They don't have to worry about who uses which IM client. They don't need to care if I self-host or use Gmail, because their ligation is simply to keep the information secure in transit.
You are also too keen to support Signal's use of phone numbers as identifiers. That's a design choice, instead of using client-managed identifiers, and makes it unsuitable for organisational use. Whose phone will we use to send the deposition to the court... and who in the court will have a phone with Signal on it? Email by contrast is universal and integrates well into organisational processes without dependency upon individuals.
Autocrypt is the middle ground Thunderbird should have implemented (and which Enigmail used to offer). Email is here to stay, so encryption by default won't happen as long as the PGP standard is used as designed (trust levels and all). Autocrypt improves all that horrible UX, including secure key transfer or rotation, where you can keep doing your own key management if you wish, but you have to do nothing more than enable Autocrypt if you don't. It's a mystery why Mozilla didn't push this, seems a perfect fit for them to empower regular web users.
I don't know much about Signal, but who manages your private key? Who does the encrypting?
With PGP there is zero chance of anyone decrypting my data unless they have my key and password, which isn't uploaded anywhere and no apps have access to it.
That would make sense for people who consider privacy as single most important measure for communication system. That is not true for everybody. The advantage of OpenPGP is that it does not break any existing advantages of e-mail (except perhaps simplicity) so it is unequivocally better than unencrypted e-mail, while other protocols may have better encryption / privacy, but are worse in other measures.
For me, open-standard-ness and federated-ness are two measures that i consider even more important than cryptographic security. So communication protocol that does not satisfy either of these have little value to me, i would rather use e-mail.
I find this kind of arguments ridiculous. Sure PGP is not perfect in all cases, but advocating not using it at all is like throwing away the baby with the bath water.
And personally, I think the points made it the linked article are weak.
Credit to the people that wrote and maintained bugzilla, both as software and this particular instance. It's still ticking, much longer than (I assume) they planned it to.
I am not so sure of that. Even time stamps cannot be trusted very much.
For example, a lot of photo cameras, audio recorders and other such devices still don’t have a small extra battery for keeping track of time. So every time you run out of battery, or in the case of wall-connected devices you unplug them from the wall, the clock is reset and time is set to some date that the device manufacturer decided to use as the epoch for their device.
And most of these devices don’t have a GPS receiver in them either, so you need to manually set the time. And only some of them will prompt you for it directly while for others you need to remember this and go in the settings menu and adjust the time.
So I routinely get time stamps that are things like 1st of January 2008, or 2015 or what have you. And sure if you notice right away you can correct it. But even when you know you sometimes get tired of that kind of stuff so you just leave it like it is.
And that’s just at the recording stage. Then you transfer files between systems and sometimes you get the original time on your files and sometimes you don’t, and even if you did they might be wrong in the first place as per above.
And all of this is for someone who knows how this stuff works and who tries as good as they can to have proper dates on files and to keep them that way. Then you have people who don’t know and don’t notice.
And then you have people who willfully modify metadata.
And then there is the data itself. We live in a post-truth age they say.
How do you know in a thousand years that the data is from when it says it was from and furthermore that there is even a grain of truth in the data itself?
I am sure there will be competent historians that are able to learn a bit of our time from our data. But I don’t think they will have it easy.
And on top of that I don’t think data can really tell the future what life today is like. It’s hard to put in words what I mean by this last point so I won’t try to say any more about that.
Recently I was delighted to find that Lurker’s Guide to Babylon 5, one of the first websites I remember really immersing myself into, is still online and even updated every now and then! I think the site has been continuously up since 1994, and most of the content is over 20 years old, published when the series was originally run. It’s a real treasure trove for any B5 fan and likely the most comprehensive and well-curated collection of B5 knowledge in the world.
Thunderbird has the only calendar I know that has a "multiweek" display as opposed to (well, in addition to) the utterly retarded month view that exists in every other GUI.
We've been doing electronic calendars for how long now? Why are we still using a paradigm from paper based calendars? At the beginning of a month I can see three weeks ahead, but at the end of the month I can see three weeks behind. It frustrates me no end that this is still a thing. It reminds me of the early days of Google maps when they were no better than paper maps, but now we can rotate the map, zoom in and out etc. But calendars are still no better than paper calendars. Apart from the one in Thunderbird.
I do think there ought to be a way to do good cryptography in email. Email is not going away anytime soon, so giving up on it as a legitimate place where cryptography is needed seems too ivory tower for me.
The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.
A slightly more realistic "dead simple solution" might be for mail clients to extend their OpenPGP support to include Autocrypt[0] which would allow users to gain some of the advantages of OpenPGP without having to understand any of the details.
S/MIME is the closest to dead simple solution, but it requires trusting certificate authorities.
It's a much better user experience, and honestly I'm surprised that no enterprise orgs have adopted it, because it would probably be cheaper than all this phishing training.
I wish to try n help with the dead simple solution. Heck, I wrote myself a wiki doc as one of my hobby projects sometime (posted here unedited so pardon me if its not perfect http://txti.es/ax4tq) for a simple, simple, simple app that would do basically signal over a SMTP-like system, if not SMTP itself for v1 bootstrapping when online, and do simple mesh relaying (ok thats probably an oxymoron) up to 7 hops when offline.
I don't feel confident enough to actually try this project yet, but at least I wrote what my ideal chat app would be, oh and came up with the fancy name 'chattaur' for it.
You could run any encrypted protocol on top of SMTP/IMAP; been there, done that; the main issue is you need specialized software on both ends to make it work.
Still, doing so solves the transport and persistence problems you would otherwise have to deal with.
21 year old bug, and Damon Gallaty apparently still works at the company that he worked at back then, albeit with some changes to the name on the checks he gets.
I have some serious feels for the guy, that had to have been a frustrating experience.
sigh Thunderbird has so many great features under the hood, but the hood is the biggest issue I have that prevents me from switching full time. Classic and wide layouts are not optimized for wide resolutions in modern laptops. Their vertical layout is unusable. The columns in the list of messages are horizontal, taking up too much width. Each layout is a tradeoff on whether I want to message pane to be usable or the list of messages to be usable.
Is anyone else having problems with this, after migrating from Enigmail on Thunderbird 68?
It fails to associate my accounts with my keys in my keyring, so I try to import an exported key. Whenever I do this, it gets stuck in a loop asking me for the passphrase for an old, revoked key :( Even after I deleted the revoked keypair -- which I know I shouldn't -- it's refusing to cooperate.
So it looks like I've actually lost this feature by upgrading...
As someone who deals with the opsec/public interface (and is a cynic about technology in general), I have to say that encrypted email via PGP has to be the computer security nerd's biggest and longest running "emperor has no clothes".
Remember when someone had to set up a GoFundMe for the one guy that was supporting OpenPGP and everything thought, "let's help this guy out" but at the same time thought Why, though?
[+] [-] capableweb|5 years ago|reply
https://bugzilla.mozilla.org/show_bug.cgi?id=22687#c1
Creepiest thing with seeing this ticket (again?) is noticing that the first comment is about that is used to be illegal to write anything with cryptographic security in the US and sell/give it to the outside world.
https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...
[+] [-] Longlius|5 years ago|reply
It works the other way too. A surprising number of countries still restrict the import of cryptographic technology, including several EU states.
[+] [-] hn_throwaway_99|5 years ago|reply
[+] [-] 67868018|5 years ago|reply
https://www.schneier.com/blog/archives/2014/11/the_return_of...
[+] [-] lucideer|5 years ago|reply
Particularly noticeable during the iOS app store[1] submission process (Android's is somewhat more lax[2] leaving the liability firmly with individual developers)
[0] https://www.bis.doc.gov/index.php/all-articles/15-policy-gui...
[1] https://help.apple.com/app-store-connect/#/dev88f5c7bf9
[2] https://support.google.com/googleplay/android-developer/answ...
[+] [-] mikorym|5 years ago|reply
But I have a more pragmatic approach. If nuclear launch codes were written out on t-shirts I wouldn't be happy about it either. I think the real problem is ignorance. The US's main role after 1945, and the role of the UN, was and is to prevent another world war. Whether by virtue or by ignorance they have been successful, with the notable exception of a partial world war in the Middle East.
Having said that, the problem is ignorance towards technology and knowledge and resentment towards talent or individual ability. It's more general fear towards things they cannot understand, or rather, things they understand that they cannot subvert. But, I don't like to reduce myself to a protagonist's syndrome and I can more or less understand why the US government does what they do.
The only real node of certainty in the whole equation is that individual freedom is where the line should be drawn. And unfortunately for the obnoxious prescriptive types, any human can invent cryptography on their own whilst living in a cave.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] dylan604|5 years ago|reply
[+] [-] libraryatnight|5 years ago|reply
[+] [-] brnt|5 years ago|reply
For reasons unclear to me Thunderbird chose not to go with something like autocrypt.org, but stick with standard PGP and implement parts of their attempt to simplify, which isn't nearly enough to get regular users on board, never mind implement things like forward security, which autocrypt does.
A missed chance from Mozilla, secure email would fit in well with their mission.
[+] [-] skyfaller|5 years ago|reply
Better to use a protocol designed with encryption in mind, like Signal, to get forward secrecy, avoid leaking metadata, and have encryption always on by default.
UPDATE: I have been reminded that PGP does not have to be used with email. I meant to say that I used to love using PGP with email, since that is the primary way I have used it. I will not comment on the use of PGP outside of email, since I haven't carefully examined its use in other contexts.
[+] [-] rendx|5 years ago|reply
(Open)PGP is first and foremost a flexible packet format (and other specs), and GnuPG is more of a CLI "library" to interface with it -- all of it. You can build something that hides metadata, you can have forward secrecy, and encryption always-on by default with PGP (and GnuPG). You can use it for whatever trust model you want, neither OpenPGP (the specs) nor GnuPG prescribe a certain model. It provides building blocks. It just happens that no good client exists and no more high level specs were written that use it, which is highly unfortunate. The client in this case here used to be "Enigmail" (a wrapper around GnuPG), and now is built-in since plugins are not allowed to be as powerful with the new browser architecture that Thunderbird piggybacks on and this was the only way to bring PGP to Thunderbird users. Also, there are some more modern libraries nowadays for standard use cases around PGP.
Signal was able to move faster since it did not exist, did not try to build things in an open and collaborative fashion, still refuses to work in any open way. Its founder Moxie even openly argues against standards [x]. I am not saying he does not have "a point", but in the long run this will lead to just more silos and ultimately technical stagnation, and for me goes against the ethos of "a public and open inter-net." (and the learnings behind it. 'Those who cannot remember the past are condemned to repeat it.')
That said, I do agree with your comment on a pure end-user level. It still makes me sad to always see this confused and not acknowledged better in places like HN, where people "should know". Technologists can defend and strive for the most promising long-term solution and "proper way to do it", and at the same time recommend "the best of the bad that is currently available". Even if it is confusing sometimes.
Just to give an example, there are plenty of high security use cases that require using smartcards. I'm very grateful that the OpenPGP standard and GnuPG exist that (can be made to) work in such cases. Signal does nothing in that space, rightfully so. But you are comparing different fruit to each other, which is kind of unfair.
[x] and still calls himself an "anarchist". You would think those know better...
[+] [-] mapgrep|5 years ago|reply
If you try to actually build a secure environment within a group that tries to maximize security while getting real work done you find you want to be encrypted by default at least with each other. Signal is pretty suboptimal for heavy volumes of messages. If you and I have three threads going they are all jumbled together. If I want to send to more than one person I have to whip out my phone and form a group and name it.
PGP is imperfect but with the right settings and defaults it is far better than having email default to clear text. And in any long term endeavor with more than a few people you will find you want email.
Signal is great for what it does. It is not designed to be a high volume working tool like email though.
[+] [-] dingaling|5 years ago|reply
Transport-level security and authentication of email content is a perfectly valid use-case for an organisation when protection against third-party interference is desired. They don't need to worry about forward secrecy, they just need attachments to be transmitted in a legally-compliant manner.
For example each month HR email me my payslip as an encrypted attachment. I decrypt it and save locally. They just have a batch job that encrypts for each user and sends. They don't have to worry about who uses which IM client. They don't need to care if I self-host or use Gmail, because their ligation is simply to keep the information secure in transit.
You are also too keen to support Signal's use of phone numbers as identifiers. That's a design choice, instead of using client-managed identifiers, and makes it unsuitable for organisational use. Whose phone will we use to send the deposition to the court... and who in the court will have a phone with Signal on it? Email by contrast is universal and integrates well into organisational processes without dependency upon individuals.
[+] [-] brnt|5 years ago|reply
[+] [-] uhtred|5 years ago|reply
With PGP there is zero chance of anyone decrypting my data unless they have my key and password, which isn't uploaded anywhere and no apps have access to it.
[+] [-] zajio1am|5 years ago|reply
For me, open-standard-ness and federated-ness are two measures that i consider even more important than cryptographic security. So communication protocol that does not satisfy either of these have little value to me, i would rather use e-mail.
[+] [-] nialv7|5 years ago|reply
And personally, I think the points made it the linked article are weak.
[+] [-] heavyset_go|5 years ago|reply
[+] [-] tingley|5 years ago|reply
[+] [-] redis_mlc|5 years ago|reply
[+] [-] aerovistae|5 years ago|reply
Reminds me of a tiny blog post I put up years ago about the future of archaeology. Forgive the silly site title.
https://meaninglessdreams.wordpress.com/2014/09/26/156/
[+] [-] codetrotter|5 years ago|reply
I am not so sure of that. Even time stamps cannot be trusted very much.
For example, a lot of photo cameras, audio recorders and other such devices still don’t have a small extra battery for keeping track of time. So every time you run out of battery, or in the case of wall-connected devices you unplug them from the wall, the clock is reset and time is set to some date that the device manufacturer decided to use as the epoch for their device.
And most of these devices don’t have a GPS receiver in them either, so you need to manually set the time. And only some of them will prompt you for it directly while for others you need to remember this and go in the settings menu and adjust the time.
So I routinely get time stamps that are things like 1st of January 2008, or 2015 or what have you. And sure if you notice right away you can correct it. But even when you know you sometimes get tired of that kind of stuff so you just leave it like it is.
And that’s just at the recording stage. Then you transfer files between systems and sometimes you get the original time on your files and sometimes you don’t, and even if you did they might be wrong in the first place as per above.
And all of this is for someone who knows how this stuff works and who tries as good as they can to have proper dates on files and to keep them that way. Then you have people who don’t know and don’t notice.
And then you have people who willfully modify metadata.
And then there is the data itself. We live in a post-truth age they say.
How do you know in a thousand years that the data is from when it says it was from and furthermore that there is even a grain of truth in the data itself?
I am sure there will be competent historians that are able to learn a bit of our time from our data. But I don’t think they will have it easy.
And on top of that I don’t think data can really tell the future what life today is like. It’s hard to put in words what I mean by this last point so I won’t try to say any more about that.
[+] [-] Sharlin|5 years ago|reply
[1] http://www.midwinter.com/lurk/lurker.html
[+] [-] sergiomattei|5 years ago|reply
[+] [-] nafey|5 years ago|reply
[+] [-] jl6|5 years ago|reply
[+] [-] globular-toast|5 years ago|reply
We've been doing electronic calendars for how long now? Why are we still using a paradigm from paper based calendars? At the beginning of a month I can see three weeks ahead, but at the end of the month I can see three weeks behind. It frustrates me no end that this is still a thing. It reminds me of the early days of Google maps when they were no better than paper maps, but now we can rotate the map, zoom in and out etc. But calendars are still no better than paper calendars. Apart from the one in Thunderbird.
[+] [-] oconnore|5 years ago|reply
The “dead simple solution” is to just run the Signal protocol over SMTP, although I’m sure it’s possible there is a better design if you were to think about the specifics.
[+] [-] dane-pgp|5 years ago|reply
[0] https://autocrypt.org/
[+] [-] epistasis|5 years ago|reply
It's a much better user experience, and honestly I'm surprised that no enterprise orgs have adopted it, because it would probably be cheaper than all this phishing training.
[+] [-] jolux|5 years ago|reply
[+] [-] Multicomp|5 years ago|reply
I don't feel confident enough to actually try this project yet, but at least I wrote what my ideal chat app would be, oh and came up with the fancy name 'chattaur' for it.
[+] [-] thaumasiotes|5 years ago|reply
1. Write the message.
2. Encrypt the message.
3. Paste the encrypted message into the email client.
Your odds of accidentally sending a message in the clear are zero.
[+] [-] codr7|5 years ago|reply
Still, doing so solves the transport and persistence problems you would otherwise have to deal with.
[+] [-] peterwwillis|5 years ago|reply
I'm pretty sure the dead simple solution is to either use SMTP or Signal and not a frankenstein's monster of both.
[+] [-] matmann2001|5 years ago|reply
[+] [-] 3np|5 years ago|reply
[+] [-] floatingatoll|5 years ago|reply
36 comments, 1 day ago: https://news.ycombinator.com/item?id=24501872
226 comments, 2 months ago: https://news.ycombinator.com/item?id=23864934
51 comments, 12 months ago: https://news.ycombinator.com/item?id=21197327
[+] [-] shp0ngle|5 years ago|reply
* I don't know
* I do NOT trust
* I trust marginally
* I trust fully
* I trust ultimately"
This is a real pop-up I got the last time I tried to use PGP with Thunderbird.
If people still get regular pop-ups like these, I don't think PGP will ever be popular.
They might have switched to PEP (pretty easy privacy) that uses TOFU (trust-on-first-use) so maybe this is thing of the past, but I don't know.
[+] [-] sulam|5 years ago|reply
I have some serious feels for the guy, that had to have been a frustrating experience.
[+] [-] btilly|5 years ago|reply
See https://latacora.micro.blog/2019/07/16/the-pgp-problem.html for why we shouldn't be using PGP in 2020.
[+] [-] PenguinCoder|5 years ago|reply
[+] [-] elchin|5 years ago|reply
[+] [-] snapetom|5 years ago|reply
[+] [-] Xophmeister|5 years ago|reply
It fails to associate my accounts with my keys in my keyring, so I try to import an exported key. Whenever I do this, it gets stuck in a loop asking me for the passphrase for an old, revoked key :( Even after I deleted the revoked keypair -- which I know I shouldn't -- it's refusing to cooperate.
So it looks like I've actually lost this feature by upgrading...
[+] [-] l0b0|5 years ago|reply
[+] [-] j45|5 years ago|reply
It also reminds me of the infamously long delay on JIRA-1369, the 20 year old ticket.
https://jira.atlassian.com/browse/JRASERVER-1369
At least it's neat software can be used for 20 years.
[+] [-] justnotworthit|5 years ago|reply
[+] [-] justinator|5 years ago|reply