> On Nov 18, 2014, at 6:48 PM, Tony Arcieri <[email protected]> wrote: > > I share similar concerns about Keybase's centralization. Beyond that, they've > created bespoke, proprietary protocols which have weird designs IMO (e.g. the > "proofs"). I expect a lot of interesting attacks against all of the existing > Keybase proofs will become possible when SHA1 second preimage attacks are > possible.
First of all, thanks for your feedback, we’re always happy and grateful when experts scrutinize the system. I don’t follow how Keybase proofs are particularly susceptible to SHA-1 2nd preimage attacks. Let’s say Bob has key k1 and has posted a proof on Github. Let’s say Mallory generates her own k2 such that SHA1(k1) = SHA1(k2), and compromises the Keybase server to reply with k2 whenever someone asks for Bob’s key. This still isn’t good enough. Someone who gets k2 will still download Bob’s signature posted on Github. He’ll check that SHA1(k2) = SHA1(k1), but the posted signature will fail to verify with k2. I realize this isn’t a formal argument of the security of the system, but it seems the required attack is much harder than just a second preimage. (And of course RFC4880 itself is buoyed by many of these informal arguments that appear to be “good enough" in practice). Another point is that RFC4880 in general will be in trouble if SHA-1 is really broken. Though RFC4880 gives flexibility of hash functions for signing message payloads, SHA-1 is the only option for key fingerprints. So key-party protocols and other back-channel exchanges of PGP keys would then be unreliable too. Wherever possible we use SHA-2, but we’re hamstrung by RFC4880 and people’s installed GPG clients. But it’s a good point, no harm in also including a SHA-2 of public keys in signatures going forward, even if some clients need to ignore them. > On Tue, Nov 18, 2014 at 12:29 PM, Maxwell Krohn <[email protected]> wrote: > Storage and availability is centralized, but not trust. Clients don’t trust > the server. > > This isn't true. A server is authoritative for a user's latest key > fingerprint. In the event of a key compromise, a user needs to update their > key, but a malicious key server can perform an attack by continuing to serve > the compromised key. Tim’s correct, the other services (Twitter, Github, etc) won’t corroborate the new (compromised) key.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
