Red Hat Bugzilla – Bug 75131
more typos in security guide
Last modified: 2014-08-04 18:14:03 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 Description of problem: Incorrect statement about 3DES being 192 bit encryption. 3DES is 168 bits (56 bit DES x 3) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Load RHL security guide. 2.Read the security section. 3.Be amazed at the additional 24 bits of security RH 3DES gives you ;-) Additional info: Chapter 6, fourth paragraph is where this is referenced. Also, "cipher" is the preferred spelling over "cypher". Also, bugzilla references this package in the description as "Official RHL Reference Guide". Shouldn't this be "Official RHL Security Guide"?
Another problem, this time in /usr/share/doc/rhl-sg-en-8.0/figs/vpn/cipe1.png It's generally considered poor taste to use someone's network addresses in examples. The nice thing to do is to use the private network addresses (RFC 1918) for your examples.
Point by point: 1) You are correct. It should have been noted that the 192 bits is derived from the subkey bits along with the additional parity bits, and that the effective strength is actually only 56 x 3 = 168 as you noted. The passage will be amended to 168. 2) I have always understood it to be 'cypher', but if conventional spelling is 'cipher', then the Guide should stick with convention as to avoid confusion. 3) In the diagram you mentioned, the attempt was to illustrate that the computer was remote and had a publicly routable IP address along with its CIPE address. I will amend it to say "remote.example.net" instead, as that is generally accepted according to RFC 2606. Thank you very much for sharing your observations. Our next version is sure to be better with reader feedback. Thanks again.
BTW, the real *effective* strength of 3DES is only 112 bits because you can do a meet-in-the-middle attack if you have a plaintext/cyphertext pair (you brute-force 56 bits of the first key by encrypting the plaintext and you brute-force 112 bits of the 2nd and 3rd key by decrypting the cyphertext. From the first step, you get 2^56 (65536 TB * data size ;-) samples, and if some of the results from the 2nd step matches, you know all three keys used. This is why 2DES is not used, breaking it takes only twice the time of simple DES. I'm not sure whether you want to bother the readers with this though ;-)