On 21/02/15 19:54, NdK wrote: >>> 4 - HOTP PINs for signature/certification keys >> What generates the HOTP then? Do you type a PIN on the HOTP device to get >> the HOTP? > No need. Just an applet on the phone could do. At least if you aren't > using the same phone to do the crypto.
I don't understand the practical difference between HOTP and the button to confirm an action. As it is now, it is the case that malware can sniff your PIN and use that to use the card. When you add a button, it knows the PIN, but can't push the button, so you're back in the loop. The malware needs an action by you, the user. If you use HOTP, the malware doesn't know the next HOTP to do an action, which means it once again relies on you to enter the HOTP. In the former, the user pushes the button. In the latter, the user enters the HOTP. What does the HOTP prevent that the button doesn't? And then I don't mean "learning the PIN", but something that is a goal of an attacker. Getting the PIN is only the means, their goal is, for instance, to decrypt or sign. What goal can an attacker achieve when only the button is there, not the HOTP? > Maybe its addition to the security is marginal, but can be *way* more > practical than having to reenter a complex PIN every time. I think the security benefit from having to enter your PIN on every access is already very marginal, and outweighed by the burden of entering the PIN. In other words, have the card remain unlocked and ready for use with a single PIN entry. If you're working on a compromised PC, you're already so screwed that your forced entry of the PIN each and every time isn't going to help. To me, the benefit of the button is that it is out-of-band. Re-entering your PIN every time is in-band, and in my eyes, not worth it. > If that info is embedded in the signature packet, it could add something > to the signature value (if the receiving party sees that signature is > about a txt file and the presented object is a doc, there's something > wrong and suspect). Are you proposing that the internal hash state after the hashing of the document is handed over to the smartcard, after which the smartcard computes the hash over the signature subpackets that you want protected this way? It's unclear to me how you see such a thing be implemented without passing all data to the smartcard. > That's the fingerprint ssh shows you. It should be computed from the > complete public key. I wasn't talking about what it shows me, I was talking about what is in the challenge that is signed. I've had a quick look in RFC 4252, with public key user authentication for SSH2. I don't think there's anything that you can show on a display that would help the user decide if it were what they wanted to see. After a really quick glance in the RFC, I see just the username and the session identifier. The username is hardly unique (I usually use peter), and the session identifier is a unique number computed for the SSH session. It's the bit that prevents signature replay attacks but is not useful to show on a display, since the user can't tell whether it's good or not: it's just the output of a hash function. All this is based on a really quick read of documentation I hadn't consulted before. It could be glaringly wrong. But when you said "it is the fingerprint", I wondered if you misunderstood or that the fingerprint is actually part of the challenge. I don't think it is. Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
