Subject: Re: [TLS] Comparative cipher suite strengths

From: Peter Gutmann <[email-masked]>
Date: Sat, 02 May 2009 21:40:40 +1200

Bill Frantz <[email-masked]> writes:

>When I think of the reasons that NSA/DOD could have for requiring AES-128 for
>secret and AES-192 for top secret, I think they may be looking at the whole
>cryptographic system.

They're also looking at the whole political system.  During a discussion among
crypto geeks some years ago someone from some branch of the USG involved with
crypto said that they were under a lot of pressure from govt-agency consumers
of crypto who were used to commercial products with keys that went up to 10,
11, and 12.  Having a single key size of (say) 128 bits would look bad when
those same govt-agency consumers could go out and buy commercial products that
were obviously stronger than the proposed government standard because they had
larger numbers behind the algorithm name.  So although there wasn't any
immediate technical reason to use larger keys, if there wasn't a capability in
AES for keys to go to 11 or 12 then it would look bad compared to non-govt-
approved crypto.

I don't know how much influence that had on the final decision, but given the
choice between having to explain for the rest of my life to one govt.agency
after another that 128 bits is good enough, and simply letting them choose
keys that go to 11 if it makes them feel better, I know which one I'd choose.

Peter.

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Sun, 3 May 2009 11:42:49 -0400

While this certainly makes a nice tea-table story, I question the "historical truthfulness" of it.

YOU may need to explain things to YOUR customers (and make them understand), lest they feel mistreated and go to another vendor. I don't think USG agencies have the same luxury of choosing their own crypto policy provider and product approver! The pressure usually is applied the other way (the "other" agency says "we want/need this", and the "crypto" branch responds "nonetheless you shall use that, and we cannot reveal to you why").

P.S. AES competition had entries with variable key sizes, I think up to 512 bits. Did it look bad - selecting an algorithm with lower maximum key length? No agency complained loud enough for us to hear, I guess?

P.P.S. If you choose so, you can define AES with independent subkeys, using PRNG to generate keys for each round from a given seed of any length you select (say 302 bits?).  :-)

P.P.P.S. KGB's encryption standard - "GOST" - was released in 1981 or 1983 (internally!) for "sensitive but unclassified" data and had 256-bit key. Design allowed independent subkeys of 512 bits (if memory serves me). And that's on a 64-bit block cipher...

On 5/2/09  05:40 , "Peter Gutmann" <[email-masked]> wrote:

Peter.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

--
Regards,
Uri
<Disclaimer>

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 03 May 2009 18:50:42 -0700

Uri and all,

  FWIW, I believe you have captured the situation spot on,
unfortunately.
"One size fits all" seems to be USG's approach to nearly every situation

when it comes to security along with other areas of consideration or
interest.

"Blumenthal, Uri" wrote:

> While this certainly makes a nice tea-table story, I question the
> “historical truthfulness” of it.
>
> YOU may need to explain things to YOUR customers (and make them
> understand), lest they feel mistreated and go to another vendor. I
> don’t think USG agencies have the same luxury of choosing their own
> crypto policy provider and product approver! The pressure usually is
> applied the other way (the “other” agency says “we want/need this”,
> and the “crypto” branch responds “nonetheless you shall use that, and
> we cannot reveal to you why”).
>
> P.S. AES competition had entries with variable key sizes, I think up
> to 512 bits. Did it look bad – selecting an algorithm with lower
> maximum key length? No agency complained loud enough for us to hear, I
> guess?
>
> P.P.S. If you choose so, you can define AES with independent subkeys,
> using PRNG to generate keys for each round from a given seed of any
> length you select (say 302 bits?).  :-)
>
> P.P.P.S. KGB’s encryption standard – “GOST” – was released in 1981 or
> 1983 (internally!) for “sensitive but unclassified” data and had
> 256-bit key. Design allowed independent subkeys of 512 bits (if memory
> serves me). And that’s on a 64-bit block cipher...
>
>
>    ----------------------------------------------------------------

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 05 May 2009 15:26:54 +1200

>While this certainly makes a nice tea-table story, I question the "historical

As I said, it was told to me by someone involved at the time, but it was some
years ago and unfortunately I didn't think to take names and numbers.

>YOU may need to explain things to YOUR customers (and make them understand),
>lest they feel mistreated and go to another vendor. I don't think USG
>agencies have the same luxury of choosing their own crypto policy provider
>and product approver!

You're assuming that the people in these organisations work like Turing
machines, and automatically follow all directives from a central authority.
Here's an instance of this kind of thing that happened to a large supplier to
the USG.  Some snake-oiler (it was either the JAWS L5 people or Meganet) were
trying to get their software adopted by this organisation.  They got a list of
contact details for people all over the organisation and called anyone they
thought would have any influence, all over the company (the person who had to
deal with some of the fallout described it as a kind of mongolian-hordes
attack, as soon as they'd stamped it out in one location it started up again
somewhere else), explaining that their algorithms were more secure because
they had bigger numbers behind the algorithm name.  This carried on for quite
some time, it was the same battle over and over again, and from the bits I
heard often came down to the security people having to say "drop this, or
else" because the target within the company didn't understand why they should
use prescribed algorithms when the snake oil was obviously better (it's quite
likely that some parts of the company, who were never discovered by the
security people, did end up using the snake oil).  You can see this (for
different organisations than the one above) with the occasional JAWS/Meganet
press release that some big customer (including USG users) have adopted their
stuff, try enough people in enough organisations and eventually they'll fall
for it, no matter how the Turing-machine model says they should react.
Meganet have even specifically targetted USG users via an active penetration
attack on FIPS 140, see their web site, complete with convenient GSA and CCR
links, for details.

Peter.

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 5 May 2009 07:31:10 -0400

>years ago and unfortunately I didn't think to take names and numbers.

Understand.

>machines, and automatically follow all directives from a central authority.

No, I'm assuming different branches of USG with different rules. Like those who design or build something, and need approval of somebody like NSA for building what they design and deploying what they build. An agency that can pretty much go outside, buy whatever - and use it internally without asking anybody's permission, nor having to pass some validation by a 3rd party - is outside of my scope of expertise (though I can assume they exist :-).

>the USG........

All I can say is "Wow!!"  Un-frigging-believable!
--
Regards,
Uri         [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Tue, 5 May 2009 15:41:05 -0400 (EDT)

> years ago and unfortunately I didn't think to take names and numbers.

Well, if Peter's recollection is not historically correct, and many such
stories get things wrong (me included---I once thought I knew the story
(from a third-hand source) about an event between RMS and ATT that
occurred before GNU was formed. I thought to check the facts with RMS,
and RMS told me I had it wrong--I heard it verbally, and didn't remember
the precise source, so I don't know if I misremembered it or my source
had it wrong.  The point is: We all fail sometimes. If Peter has the
history wrong, please state the correct history with your sources of
fact. Just saying Peter has it wrong is no help.

> You're assuming that the people in these organisations work like 
> Turing machines
[...]
> because the target within the company didn't understand why they should
> use prescribed algorithms when the snake oil was obviously better 
[...]
> try enough people in enough organisations and eventually they'll fall

Yep, that about covers it.  I think we all probably have to deal with
snake-oilers at some time or other. And my experience is about the same:
its tedious. It seems to be a colossal waste of time. Fortunately or
unfortunately, the snake-oiler's I'm currently fighting keep sending me
a reminder once or twice a month to do a little more work... ;-)

But snake-oil has to be discredited on its de-merits, not by altering
specifications to encompass both snake-oil and non-snake-oil.  The best
thing you can do is put up a web page discrediting the snake-oilers to
help others do the same. And promote the non-snake-oil on its 
comparative merits until people catch on.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Tue, 5 May 2009 16:23:48 -0400 (EDT)

I think this Schnier "Cryptogram" is particularly insightful on the 
subject of Snake oil, and even mentions the issue of AES key lengths.  I 
found it by googling for "JAWS L5 Meganet".  :-)

http://www.ussrback.com/crypto/misc/cryptogram-021599.txt

		--Dean

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 6 May 2009 22:27:07 -0400

On Thu, 30 Apr 2009 18:56:35 -0700
Bill Frantz <[email-masked]> wrote:

> When I think of the reasons that NSA/DOD could have for requiring
> AES-128 for secret and AES-192 for top secret, I think they may be
> looking at the whole cryptographic system. While symmetric cyphers
> have some solid math behind them, other parts of the system, such as
> generating random numbers for the keys are frequently more akin to
> black magic.
> 
From http://catless.ncl.ac.uk/Risks/15.48.html#subj1

	The unit key is generated via Skipjack itself, from random
	seeds provided by the two escrow agencies (approximately
	monthly, though that isn't certain yet).  They say they prefer
	a software generation process because its correct behavior is
	auditable.

In other words, the NSA understands that keys should not be generated
by a random process.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb