More on 128-bit vs. 256-bit security

Matt Ball matt.ball at
Sun Sep 16 17:41:37 PDT 2007

Formatted message: <A HREF="r0709166_f.htm">HTML-formatted message</A>

Hi All,
I strongly support David's statements below, and want to add one more point
about tape encryption:
Even though most tape devices have standardized on 256-bit AES encryption
(such as that described by IEEE P1619.1), 128-bit (or even 112-bit) security
is sufficient protection for the encryption key as it passes across the
bus.  It's important to realize that the threat model for sniffing
encryption keys across the SCSI bus is different than the threat model for a
lost backup tape.  In the first case, the attacker has to infiltrate the
company's data center, which requires either physical access or a breach in
the company firewall.  In the second case, the adversary typically has an
easier time stealing the backup tape because the tape has to physically
travel off-site to provide disaster protection.
P1619.1 picked 256-bit security for a couple reasons:
1) 256-bit AES provides more margin in case someone cracks 128-bit AES (So
far, 7-round 128-bit AES is vulnerable, providing 3 rounds of margin --
256-bit AES has 5 rounds of margin).
2) Tapes can have a shelf life of 30 years, so we wanted a higher level of
3) 256-bit AES is only slightly slower than 128-bit AES (This is not true of
equivalent strength public-key operations)
The bottom line is that your company doesn't automatically have to choose
the 256-bit suite for IKEv2-SCSI just because you use 256-bit AES for
encrypting your tape data.  The 128-bit IKEv2-SCSI suite still provides very
good protection, while making things much easier from both the business-side
and engineering-side.
On 9/16/07, Black_David at <Black_David at> wrote:
> * From the T10 Reflector (t10 at, posted by:
> * Black_David at
> *
> Between the 128-bit suite and the 256-bit suite in IKEv2-SCSI
> (06-449), I think the 128-bit suite is the clear choice, because:
> (1) I agree with Hugo Krawczyk that the 256-bit suite is overkill,
>	  and the NIST document that Larry Hofer has cited supports
>	  this view.  The overkill is quite dramatic, as the 256-bit
>	  suite contains the 521-bit elliptic curve, which is beyond
>	  even NSA's most stringent suite B requirements.
> (2) I place little reliance on the NSA's guidance in the documents
>	  that Gideon has provided pointers to.  NSA is part of the US
>	  government security community that brought us Skipjack and
>	  DSA digital signatures, neither of which are in in widespread
>	  commercial usage.  The NSA determination not to use RSA and
>	  DH MODP key sizes larger than 1024 bits ("NSA has determined
>	  that beyond the 1024-bit public key cryptography in common
>	  use today, rather than increase key sizes beyond 1024-bits,
>	  a switch to elliptic curve technology is warranted.") looks
>	  like it's going to follow in this fine tradition of commercial
>	  failure.  We are likely to eventually need elliptic curve to
>	  deal with RSA and DH MODP scaling issues, but 1024 bits is
>	  *not* the inflection point.
>	  But wait, it gets better, because NSA hasn't even convinced
>	  the entire US government to sign up for their view.  Not only
>	  is NIST not convinced (there are RSA and DH MODP key sizes
>	  larger than 1024 bits in the document Larry cited), but there
>	  is even disagreement within the US Department of Defense
>	  itself.  For example, the current draft of the DISA IPv6
>	  profile for the DoD:
> (
> _v2.pdf)
>	  requires RFC 4307, and in turn RFC 4307 recommends 2048 bit
>	  MODP Diffie-Hellman as the successor to 1024 bit MODP DH.
> (3) The intellectual property situation around elliptic curve is a
>	  problem.  I join Kevin in stating that "we cannot support as
>	  mandatory, items that fall under the IP of companies that do
>	  not make a RAND statement to T10 related to that IP."  I
>	  believe Gideon has known for months that obtaining such a
>	  statement would require something like his company approaching
>	  the patent holder; if anything has happened, he should say so.
>	  In any case, T10 does not currently have a RAND statement
>	  for this technology, and assuming that one will appear is
>	  (IMHO) seriously optimistic.
> As indicated in my previous email "Single suite requirement?", I'd
> be prepared to remove the 256-bit suite from 06-449 and instead ask
> for a vote on whether the 128-bit suite should be mandatory or not.
> If the 256-bit suite remains, one way to look at the choice between
> it and the 128-bit suite is to decide whether to follow the approach
> of the NSA and the related poor track record of the US government
> on commercial security technology, or the approach of Hugo Krawczyk,
> RSA and the IETF security community that has developed security
> technology that is in widespread commercial use around the world
> (e.g., TLS, IPsec).  I think that choice is obvious, but then I
> regard myself as part of the IETF security community.
> Thanks,
> --David
> > * From the T10 Reflector (t10 at, posted by:
> > * Black_David at
> > *
> > I asked some RSA colleagues to look at the 128-bit and 256-bit
> > suites.  They noted that the P-521 elliptic curve (521 bits)
> > may be excessive for the 256-bit suite.  For example, the
> > largest elliptic curve required by NSA suite B is the 384 bit
> > curve:
> >
> >
> >
> > Thanks,
> > --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953		FAX: +1 (508) 293-7786
> black_david at	     Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at
Matt Ball

More information about the T10 mailing list