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 protection.
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.

Thanks,
-Matt

On 9/16/07, Black_David@emc.com <Black_David@emc.com > wrote:
* From the T10 Reflector (t10@t10.org ), posted by:
* Black_David@emc.com
*
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:
(http://jitc.fhu.disa.mil/adv_ip/register/docs/disr_ipv6_product_profile
_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@t10.org), posted by:
> * Black_David@emc.com
> *
> 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:
>
> http://www.nsa.gov/ia/industry/crypto_suite_b.cfm
>
> 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@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo@t10.org



--
Thanks!
Matt Ball
IEEE SISWG Chair
303-717-2717
http://www.linkedin.com/in/matthewvball