221–230 of 369 posts
There's a few places where this engages in goalpost shifting that seems less than helpful even though I end up agreeing with the general thrust. Let's focus on one: > Put a Signal number on your security page to receive bug bounty reports, not a PGP key. We can reasonably assume in 2019 that this "security page" is from an HTTPS web site, so it's reasonably safe against tampering, but a "Signal number" is just a phon…
Telling people to treat email as insecure and thus not use it for anything serious is terrible bad advice. I am reminded of BGP (Border Gateway Protocol). Anyone who has even glanced at the RFC of BGP could write an essay of the horrible mess of compatibility, extensions, non-standard design of BGP. It also lack any security consideration. The problem is that it is the core infrastructure of the Internet. Defining so…
FYI, Robert J. Hansen's comment in gnupg-users@gnupg.org.[0] 0) https://lists.gnupg.org/pipermail/gnupg-users/2019-July/0623...
Really, all I did here was combine posts from Matthew Green, Filippo Valsorda, and George Tankersley into one post, and then talk to my partner LVH about it. So blame them. (also 'pvg, who said i should write this, and it's been nagging at me ever since)
Is it wrong to use openssl to encrypt files? 0. (Only once) generate key pair id_rsa.pub.pem, id_rsa.pem 1. Generate random key openssl rand -base64 32 > key.bin 2. Encrypt key openssl rsautl -encrypt -inkey id_rsa.pub.pem -pubin -in key.bin -out key.bin.enc 3. Encrypt file using key openssl enc -aes-256-cbc -salt -in SECRET_FILE -out SECRET_FILE.enc -pass file:./key.bin -- other side -- 4. Decrypt key openssl rsautl…
There's a few places where this engages in goalpost shifting that seems less than helpful even though I end up agreeing with the general thrust. Let's focus on one: > Put a Signal number on your security page to receive bug bounty reports, not a PGP key. We can reasonably assume in 2019 that this "security page" is from an HTTPS web site, so it's reasonably safe against tampering, but a "Signal number" is just a phon…
> persistent global public identity Certificate Transparency could be reused/abused to host it. If, for example, you issued a cert for name .contact.example.com and the tooling would check CT logs this could be a very powerful directory of contacts. Using CT monitors you could see if/when someone tampers with your domain name contact keys. Mozilla is planning something similar for signing software: https://wiki.mozil…
Earlier quoted context omitted.
You might be surprised just how many mail providers support STARTTLS for email, at least opportunistically. https://www.fastmail.com/help/technical/ssltlsstarttls.html
And opportunistic STARTTLS is vulnerable to downgrade attacks by MITM. the problems with email are that, no matter how sure you are that the connection between you and your mail server, and your local and server storage, are secure, the parties you may be interacting with are not. And then, as is talked about in the article, your recipient forwards the mail as plaintext...
Not supported by everyone just yet since this is a new standard, but Gmail at least supports it.
> there’s a simple meta-problem with it: it was designed in the 1990s, before serious modern cryptography SSL was designed in 1994 but it has been properly maintained and today no-one argues that TLS should be replaced by noise/strobe etc. OpenPGP's problem no 1. is that there are no parties using it on a wider scale and interested in improving it.
That's what didn't happen with PGP.
I understand that there are better tools for encryption, but is there anything that replaces the identity management of PGP? Having a standard format for sharing identities is necessary in my opinion. If I have a friend (with whom I already exchanged keys) refer me to some third friend, it would be nice if he can just send me the identity. Sending me the signal fingerprint isn't a solution for two reasons: - I don't…
People often think it must be the opposite but this is essentially emotional reasoning: the Web of Trust feels decentralised, social, "webby" un"corporate", free, etc. All things that appeal to hobbyist geeks with socialist or libertarian leanings, who see encryption primarily through the activist lens of fighting governments / existing social power structures.
But there's nothing secure about the WoT. As the post points out, the entire thing is theatre. Effectively the WoT converts every PGP user into a certificate authority, but they can't hope to even begin to match the competence of even not very competent WebTrust audited CAs. Basic things all CAs are required to do, like use hardware security modules, don't apply in the WoT, where users routinely do unsafe things like use their private key from laptops that run all kinds of random software pulled from the net, or carry their private keys through airports, or accept an email "From" header as a proof of identity.
I wrote about this a long time ago here:
https://blog.plan99.net/why-you-think-the-pki-sucks-b64cf591...
I understand that there are better tools for encryption, but is there anything that replaces the identity management of PGP? Having a standard format for sharing identities is necessary in my opinion. If I have a friend (with whom I already exchanged keys) refer me to some third friend, it would be nice if he can just send me the identity. Sending me the signal fingerprint isn't a solution for two reasons: - I don't…
But even that's still not quite what I'm looking for. There's no straightforward way to link arbitary protocol accounts / identities to it, outside of linking plain URL:s.
We need something a bit smarter than keybase that would actually allow you to maintain a single personal identifier across multiple protocols.
I use my PGP key (with a Yubikey) for two things, the pass password manager and as an SSH authentication key. Is there a replacement for those two use cases where I can store my private key on a hardware token?