> - Don't choose algorithms for security, choose protocols for > security.
That sounds completely backwards to me. When we have a set of security requirements, the first thing we do is select the algorithms that meet those requirements, then we look for protocols that implement them. For example, suppose I need to synchronize files across a network. The first thing I would do is ask what algorithms are suitable. Is compare by hash okay? Do I need encryption? Do I need compression? Then, with a list of algorithms that suit my requirements, I can look at protocols that implement them. You can't look at the protocols first. For example, SSL can be used with many different algorithms. So can SSH. So asking, "does SSL meet my requirements" isn't really even possible without recursing into the algorithms it supports. > - The right protocol will have a sensible set of algorithms to > go with it, in some cases choose the appropriate subset of > parameters within the protocol to yield the right security, > performance and interoperability tradeoffs. That's, largely, what makes it the right protocol. If we want secure compare by hash, then almost any sync protocol that uses SHA-256 will be fine but almost any that uses MD5 will not. Why? Because SHA-256 is good for compare by hash and MD5 is not. Any protocol that's not brain-damaged that uses SHA-256 will work, and any that uses MD5 will not. > - Do not be tempted to design new algorithms (most IT people know > this). Definitely. This is an absolute disaster in almost all cases. > - Do not be tempted to design new protocols (most IT people don't > know this). This is less of an absolute disaster and doesn't have as many pitfalls as trying to design your own algorithm. But you are absolutely right that it does contain a significant set of potential hazards. > Viktor DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
