it isn't sufficient that you show there is some specific authentication protocol with unread, random data ... that has countermeasures against a dual-use attack ... but you have to exhaustively show that the private key has never, ever signed any unread random data that failed to contain dual-use countermeasure attack.

Why isn't it sufficient? (Quick: when was the last time anyone on this list authenticated by signing unread random data?)

The way the industry is going, user keypairs live in a desktop keystore, and are used for very few applications. I'd bet the vast majority of usages are client-side SSL, signing, and encryption.

If this de facto universal usage suite contains exactly one authentication protocol that has a built-in countermeasure, then when this becomes solid, we're done.

Our energy would be better spent on the real weaknesses: such as the ease of getting desktops to just cough up the private key, or to use it for client-side SSL without ever informing the user.

And on the real problems: such as using the standard suite to get the trust assertions to match the way that trust really flows in the real world.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to