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.
--Sean
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
