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):
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 ;-)
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
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.
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 ;-)