On 2/13/06, Peter Gutmann <[EMAIL PROTECTED]> wrote: > >I would expect that typically implementors would be following a published > >standard, which would (well, one would hope) have had expert cryptographers > >check it over sometime prior to publication
Published implementations aren't immune to errors, and quite frequently they don't even explicitly specify what/whom they're protecting against. Using one incorrectly or inappropriately presents the same pitfalls as using one de novo. There's also an absence of easily accessible information which describe the various protocols, their design parameters, their constraints, their threat models, their dependencies, their availability, their patent status, their licensing status, status with regard to prior flaws, etc. I know this has been asked for before, when someone got the standard "reuse a published protocol" answer. For example, there's a popular program called stunnel which uses openssl to secure connections. This ostensibly is a shim for protecting cleartext protocols such as POP. However, unless it does significant length padding or in some other way (maybe compression?) decouples the length of the messages from the length of the ciphertext transmissions, you can still probably derive a lot of information from a version identifcation and the length of the human-readable strings which follow the ^[0-9][0-9][0-9] machine-readable responses, and knowing the standard order of interaction. From browsing the online documentation, I find stunnel basically saying "it's really just openssl", and from browsing the openssl documentation, I can't figure out whether it does any length padding at all. I think it's unrealistic to have to read source to find out this kind of information. I think that there's a noteworthy level of skill between being able to design a secure block cipher (what I call a cryptologist) and being a newbie. I think that someone with those intermediate skills can probably cobble together existing building blocks into a decent protocol. They should, however, do the homework on the various protocols and attacks, publish their protocol (to this list?) before implementing it, run a finite-state analysis against it with the standard assumptions as a sanity check, keep up to date on the weaknesses of any building blocks they use, and maybe hire an expert cryptanalyst to try and break it (of course he will probably prefer to design it, but the premise is that won't happen). Doing this is not exactly easy -- I had a hard time finding any descriptions of protocols for 2-party mutual authentication in my limited literature several years ago when I did the crypto and networking for a distributed HIDS. I ended up factoring one of the parties out (i.e. merging two parties) of a 3-party authentication algorithm published in AC. Speaking of which, there's an error in the 2ed 5th printing, on pp 61, the Neumann-Stubblebine protocol, step (3) --- the text is correct but the symbolic notation should read: E_A(B,R_A,K,T_B), E_B(A,K,T_B), R_B I have verified this against the original paper, and the error is obvious if you think about what's going on. I sent a correction to the email black hole that is Schneier. I only know of a few attacks strictly on protocols (replay, version rollback, reflection, MITM/chess grandmaster), and I think all are easily derived from some simple rules in a finite state analysis (attacker can replay, attacker can observe, attacker can modify, attacker can impersonate &c.). If I am mistaken, please illuminate me. Speaking of this makes me want to write such a set of wiki pages somewhere. So if anyone would kindly send me a list of protocols and algorithms they'd like to see covered, I'll compile it and maybe fill in some stuff on a wiki with it. I'm sure it would be a useful learning exercise, as well as a public service. I'm mostly interested in illustrating modern protocol details (e.g. SSL v3, SSHv2, ISAKMP, WEP, WPA, WPA2, IEEE 802.1x?, Photuris?), reviewing libaries (e.g. openssl, cryptlib), and describing the use of APIs (GSSAPI, SASL) but I'm also interested in the strength of primitives (AES, SHA1, etc.) as defined by recent attacks. > It also defends against the MD5 crack, and is one of the recommended > IETF solutions to hash problems. Cool :) Another idea I had was to uniquify the hashes using some sort of machine-specific key to prevent them from being broken on a different machine, but it'd still need to be stored on disk across reboots. With PK you could create a keypair, one for encrypting (making a password hash) and one for decrypting (validating a password hash), and you'd only have to protect one or the other. Perhaps making password hashes could be done offline. Another way to slow down brute force is to require a search for a correct input to the password-verifying algorithm (for example, don't prepend the whole IV to the hash). A cracker would have to exhaustively test the input space for every incorrect guess at the password, whereas a valid password would require one half the amount of computation (on average), ignoring collisions. -- "Cryptography is nothing more than a mathematical framework for discussing various paranoid delusions." -- Don Alvarez http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]