|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: ABOVE.NET SECURITY TRUTHS?
> Not quite true. Sure, Netscape ran into that problem with early SSL > code, in Navigator v3.0, but there are known solutions. After all, > Netscape found it. Are you speaking towards a specific vulnerability > in SSH, or just theory? I am not aware on such a vulnerability in SSH, > or SSHD, either version 1 or 2. I am not speaking of any particular vulnerability in SSH, SSHD or any specific algorithm in general. I do not want to get into a discussion of whether 3DES is safe or not, whether IDEA is safe or not etc. Everything uses a key, the strength of the data encoded by an algorithm is determined by the quality of that key. In general implementation, Diffie-Helman is used to negotiate a set of public key (RSA) style keys, which are then used to generate session keys for the underlying (somewhat faster algorithm). If the key used to generate the initial keys is predictable, everything else is too. They all operate on the concept of using an algorithm (on the host/key generating system) to create numbers of a "specific randomness." There is no element that can be used for programming in systems that is at all random, and usually just time indexed fourier algorithms. That is all. All Netscape did was add a few more variables to their "randomness" to make it less less to approximate it. Using nuclear decay plots (from a live isotope) used to be a good source for randomness too, but then they figured out how to approximate that too. This is not sci.crypt, so I suspect I am seriously off topic. There are plenty of well understood methods to prevent commercial sabotage/espionage, none of which involve cloak and dagger stuff. Implementing technology without establishing/training your human staff properly is nearly useless; if you are trying to protect against someone who knows your procedures and has the slightest bit of motivation to screw with you. Deepak Jain AiNET
|