41–50 of 148 posts
Earlier quoted context omitted.
ssh covers ssh and now signing, eg for git commits. The vouching and web of trust stuff never worked for mist people.
Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards. Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
Earlier quoted context omitted.
I've done similar work and would not describe myself as a cryptography engineer, just a systems person with a security specialization. (I've been pretty consistent about this point on HN, this isn't just something I'm saying because it's convenient for the thread). When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. How do you respond…
> When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. I am not going to drag anyone else or their reputations into this conversation but they can chime in if they want to. The general vibe I get about PGP among the cryptography engineers in my universe, that I share, is that it is an awkward spec that would have never been designed to…
https://articles.59.ca/doku.php?id=pgpfan:index
Anyways, at this point my feeling is that you've essentially conceded the actual point I was making (that PGP is itself also a shitshow of 1990s cryptography), and answered that you just don't care that it is. That's a perfectly coherent point to make and not one I'm super interested in litigating today.
Earlier quoted context omitted.
Every time I get a dev or executive sending me a Slack message saying "can you reset my password" or "can your provision me in...", my very next reply is "please send me your public key". They do not get their credentials until they do so. And once they do, our security posture gets better and better.
I think I'm missing something, how does asking for their public key improve security or verify their identity?
Earlier quoted context omitted.
Every time I get a dev or executive sending me a Slack message saying "can you reset my password" or "can your provision me in...", my very next reply is "please send me your public key". They do not get their credentials until they do so. And once they do, our security posture gets better and better.
I think I'm missing something, how does asking for their public key improve security or verify their identity?
Earlier quoted context omitted.
Every time I get a dev or executive sending me a Slack message saying "can you reset my password" or "can your provision me in...", my very next reply is "please send me your public key". They do not get their credentials until they do so. And once they do, our security posture gets better and better.
I think I'm missing something, how does asking for their public key improve security or verify their identity?
Earlier quoted context omitted.
Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards. Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
Why do you call it abuse?
Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subkey system, CA, or rotation strategy, or the ability to revoke a key for one use case without compromising others or forcing a full keychan rotation.
Telling people to use a single private keypair for many unrelated use cases has always been short-sighted cryptography advice and still is.
I get that gpg UX is remarkably bad and makes everyone want to run screaming from PGP, but modern tooling exists now and for all the things the PGP spec got wrong, it got a lot more right.
Watching new solutions get wrong the few things PGP got right as an answer to PGP is kind of infuriating.
Earlier quoted context omitted.
Why do you call it abuse?
OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions. Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subk…
Earlier quoted context omitted.
Even if you ONLY care about encrypting files presumably you want to be able to decrypt them far into the future, with confidence no one else can do so. If that is the case, you probably want: 1. a long lived keychain 2. a way to securely load private keys into smartcards such that they cannot be stolen by malware 3. a strategy to recover lost keys 4. a strategy to migrate from one keychain to another one 5. a way to…
It’s unclear to me any stateful keychains are implied here. The decrypting system has N number of keys available. It tries to authenticate the ciphertext with those N keys. If the ciphertext authenticates, then return the decrypted cleartext. What’s more, it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer. All that is needed for that hi…
Encrypted files are encrypted to a key. It could be a one time use key encrypted to another key as PGP and Age both do, but still there is a long lived secret a user must maintain somewhere, somehow, and have a strategy for backup, rotation, discovery, validation, etc etc.
> it’s unclear to me why point 5 belongs in the cryptosystem layer (such as with PGP) rather than on some higher, more adaptable layer.
There are a ton of other ways these problems could be solved. If we had a time machine we would go back and design way different tools and specs to address the problems PGP solves. We would redesign the internet too.
What I take issue with is people recommending age or minisign or signing with ssh keys when all of these just pretend the problems PGP solves do not exist, and thus set people up to fail.
Earlier quoted context omitted.
> When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. I am not going to drag anyone else or their reputations into this conversation but they can chime in if they want to. The general vibe I get about PGP among the cryptography engineers in my universe, that I share, is that it is an awkward spec that would have never been designed to…
Are you sure you want to be citing that particular site to defend the MDC? Do you co-sign other things it says? https://articles.59.ca/doku.php?id=pgpfan:index Anyways, at this point my feeling is that you've essentially conceded the actual point I was making (that PGP is itself also a shitshow of 1990s cryptography), and answered that you just don't care that it is. That's a perfectly coherent point to make and not…
Also I never actually disagreed that PGP as a specification, has a lot of 1990s holdovers given its history and age. Thankfully we have modern tooling now with reasonably secure defaults.
I was mostly arguing against the article you shared whose conclusions I absolutely disagree with.
IMO OpenPGP, however aged the spec design, when used with modern tools in turn using the unified smartcard interfaces, is still a way better choice than a hodge podge of ssh keys, minisign, age, openssl, etc without any standardized solutions for key revocation, rotation, backup, discovery, verification, etc.
Earlier quoted context omitted.
Why do you call it abuse?
OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions. Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subk…