[Mike Hearn wrote]: >> The UI for this is terrible, but if you click the little tick symbol next to >> "Signed" then it will open a certificate viewer and you can see the >> certificate+fingerprint used to sign.
OK - I missed "Details" before, in OSX Mail I can see what's encrypted and in a few clicks find a fingerprint. That's not bad - It would be nice to see a "Johnny"-type study on opportunistic S/MIME in modern clients. [Tom Ritter wrote]: >> A mail header certainly has the issue of a privacy-preserving way of >> fetching it, but I find key attachments to be ugly and confusing to >> non-users. I feel like there must be some way in the MIME world to >> stash a key somewhere that's hidden from clients but accessible to the >> machine. Stick the public key in a header? If we're sending EC keys and not trying to convey PGP key blobs, this is nothing (32 bytes). [Mike Hearn wrote]: >> But normally you want to authenticate after encryption, right? Otherwise >> there can be odd attacks based on bit-flipping that can result in a message >> that decrypts successfully but doesn't say what the sender thought they said. There's a subtler reason you want to authenticate the ciphertext *before* decrypting. If you don't do that, interaction of tampered data with parsing code, prior to authentication, might leak info about the rest of the plaintext through error messages or timing (a source of TLS problems due to its MAC-then-Encrypt structure). S/MIME and PGP commonly do authentication via signatures inside the encryption (I believe the formats are flexible, but this is the common approach). PGP added the MDC, but it's still inside the encryption, and as Andy points out there's a lot of processing after decryption but before the MDC is checked (e.g. decompression). So you don't want to expose PGP or S/MIME decryption errors or decryption timings to untrusted parties. (I don't know that anyone's worked out the details, but there was some work on PGP as a decryption oracle before MDC was added [1], and also using PGP's ad-hoc CFB integrity check as an oracle [2]). [Elijah wrote]: >> There are a couple problems with the OpenPGP header. I could craft an >> email that purports to be from [email protected] with an OpenPGP header of >> my choosing. Maybe the recipient's client is smart and only accepts >> OpenPGP header when the from header is DKIM signed. Even in this case, >> both the sender's server and the recipient's server could inject a bogus >> OpenPGP header. OK, so it seems like your objection isn't the details of the OpenPGP header, but with the *concept* of receiving a public key through email and deciding to encrypt based on that. So you're proposing to use the email header *not* to convey the public key, but simply to indicate which of several other infrastructures to query the key from (DANE? keybase? etc). I don't totally get this - if you don't trust the email header to give you a public key, why do you trust it to tell you where to look up the public key? [Dkg wrote]: >> OpenPGP signatures currently don't contain the full public key or >> even a full fingerprint. What's present is the 64-bit "long keyid", >> which i don't think is sufficient Assuming the fetched public key has to verify the signature, the forger has to solve two problems (match the 64-bit key ID and do a "duplicate signature key selection"). I believe these are individually possible, at least for RSA. Whether it's feasible to solve these simultaneously I don't know, someone would have to do the math. [David Gil wrote]: >> Using the same key for signing as for encryption gets vastly weaker >> security guarantees (i.e., Gap-DH for EC). Depends, see [3]. Also, Gap-DH is a conventional assumption. If it bugs you Strong-DH can often be substituted, but people rarely bother. If you were thinking of [3] note that Gap-DH/ROM is used there for standard EC encryption, it's not an artifact of combining encryption with signatures. Trevor [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.25.3816 [2] https://eprint.iacr.org/2005/033.pdf [3] https://eprint.iacr.org/2011/615 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
