> Every well-known bad cryptosystem eventually sprouts an RFC extension that supports curves or AEAD, so that its proponents can claim on message boards that they support modern cryptography.
I'm being attacked! :P
The PGP Problem
291–300 of 369 posts
Re: The PGP Problem
#292For backups, I would recommend Restic. The author mentions Tarsnap, and if you don't want to back up five terabytes that is probably great, but after a few gigabytes it's just not economical for private persons. If you're on hacker news (i.e. the 'engineer' the author was talking about), odds are that storing a hard drive connected to a raspberry pi at your parents' and using Restic as client is an extremely cheap wa…
I have a few gigabytes on tarsnap for pennies a day.
Re: The PGP Problem
#293I read these advice columns like "You should stop using hand saws because we now have electric saws which are better in every way that I care about." Great! You use them then. I'll keep using crufty old hand saws wherever I want, you use and proselytize your electric saws and we can get on with our lives. I have my own networks and threat models and my own evaluation functions for these. Hand saws are pretty good.
Re: The PGP Problem
#294Earlier quoted context omitted.
So if I understand you correctly (Noob here), Alice would need to sign the pair (key.enc, file.enc) to authenticate that those files originated from her. Without that, Bob could potentially receive any pair of (key,file), which would just decrypt into garbage data. BTW, variations on that sequence appear all over the internet when searching for "openssl encrypt file with public key"...
This is one of the problems with cryptography: with a little knowledge, you can end up making yourself completely insecure while believing yourself to be very secure. People generally imagine that "encrypt this block of data" is a simple primitive that does everything you want it to. But naive encryption doesn't work like that. In the worst case, where you use ECB for the block cipher [1], you end up with the ECB pen…
[1] This is so bad it shouldn't ever be an option in any tool.
And yet it's effectively the default.
Re: The PGP Problem
#295Glad to see wormhole listed here, I hadn't seen it recommended by security experts before. Is there also a similar consensus about Syncthing and whether it is secure enough for long-term file-sharing?
Re: The PGP Problem
#296Earlier quoted context omitted.
Really? When gmail came out they were explicitly up front about using the content of the email to deliver targeted ads. Has that changed?
There are a lot of misinformations around, and the Google haters crowd has plenty of pitchforks. https://safety.google/privacy/ads-and-data/ > Google does not use keywords or messages in your inbox to show you ads. Nobody reads your email in order to show you ads.
Are we sure about this? When I downloaded my Google data, I fished around and found information related to my Amazon purchase history and etcetera. The only possible way that I can think of that Google is able to get my purchase data is from my email.
Re: The PGP Problem
#297I was an engineer at PGP from 2004-2011 and ended up running the server team as lead engineer. I wouldn't disagree with most of the points brought up by the author, both the code base and standard has accreted over time and it's incredibly complex. There were only a couple of people on the team that really understood all the facets of either the OpenPGP or SMIME/x509 standards. It's made worse in that it was a hack o…
> The sub-packets that the author mentions were primarily used for dealing with forwarded chains of encrypted email messages where each previous message had it's own embedded mime-encoded encrypted/signed messages and attachments.
If you ("you" here being the PGP team) knew going into the design that the use-case of ASCII-armored-binary (.asc) documents is specifically transmitting them in a MIME envelope... then, instead of making .asc into its own hierarchical container format, why didn't you just use MIME, which is already a hierarchical document container format?
I.e., if you're holding some plaintext and some ASCII-armored-binary ciphertext, why not just make those into the "parts" of a mime/multipart container, and send that as the email?
Then all the work of decoding—or encoding—this document hierarchy would be the job of the email client. The SMIME plugin would only have to know how to parse or generate the leaf-node documents that go into the MIME envelope (and require of the email client an API for retrieving MIME parts that the SMIME parts make reference to.)
And you'd also get the advantage of email clients showing "useful" default representations for PGPed messages, when the SMIME extension isn't installed.
• Message signature parts would just be dropped by clients that don't recognize them. (Which is fine; by not having SMIME installed, you're opting out of validating the message, so you don't need to know that it was signed.)
• Encrypted parts would also be dropped, enabling you to send an "explanation" part as a plaintext of the same MIME type to the "inner" type of the encrypted part, explaining that the content of the message is encrypted.
I guess this wouldn't have worked with mailing lists, and other things completely ignorant of MIME itself? But it would have been fine for pretty much all regular use of SMIME.
Re: The PGP Problem
#298Earlier quoted context omitted.
Really? When gmail came out they were explicitly up front about using the content of the email to deliver targeted ads. Has that changed?
There are a lot of misinformations around, and the Google haters crowd has plenty of pitchforks. https://safety.google/privacy/ads-and-data/ > Google does not use keywords or messages in your inbox to show you ads. Nobody reads your email in order to show you ads.
That's not misinformation - it's just mildly dated information. Google stopped scanning emails for ads very recently.
It was never a conspiracy theory. Google used to be very open about the fact that they were scanning emails.
Re: The PGP Problem
#299With the rapid churn of various chat clients it's hard to get something to stick, and I attempted to settle on XMPP+OMEMO (or OTR), since it's a protocol, not an "app" (eww). Not a single person I know still uses XMPP, and it's easier to just tell people "Download Signal". However, that requires a phone number, and is useless on a desktop if your phone's off. Despite being Free Software, it's fairly locked down. Secu…
Signal Desktop has never required your phone to be on. It's completely independent once set up (apart from the occasional contact list sync). It has been this way since the first version of Signal Desktop. You're probably thinking of WhatsApp Web, which works the way you describe. I've seen this incorrect information spread on HN too many times, and I'm not sure how so many people came to think that. It's been 100% w…
You are correct. Thanks for pointing that out; I tested it out this morning and verified I was able to send/receive messages on the desktop program with my phone in airplane mode.
Re: The PGP Problem
#300I read these advice columns like "You should stop using hand saws because we now have electric saws which are better in every way that I care about." Great! You use them then. I'll keep using crufty old hand saws wherever I want, you use and proselytize your electric saws and we can get on with our lives. I have my own networks and threat models and my own evaluation functions for these. Hand saws are pretty good.
If your threat models have you using PGP, your threat models are badly engineered.