More on 128-bit vs. 256-bit security

Gideon Avida gideon at decru.com
Mon Sep 17 20:53:32 PDT 2007


* From the T10 Reflector (t10 at t10.org), posted by:
* "Gideon Avida" <gideon at decru.com>
*
Hi All,
Decru is been shipping products that provide the user with 256 bits of
security end to end. We've started selling these products before the NSA
published Suite B. In discussions with our customer base and potential
customers (both government and civilian), we've learned that they value the
security we provide, and would like us to continue providing it, regardless
of Suit B. Therefore our plan is to continue making, and selling, such
products. (This should answer the ECC 384 vs. 521 question).
The days when a tape drive was locally attached by a single physical cable to
the server are mostly gone. With virtualization, replication and remote
disaster recovery, it is difficult to track where things go or who might be
able to intercept them. So, as mentioned in previous messages, some customers
find it valuable to have the ability to claim 256 bits of security
end-to-end. This way, they don't have to analyze their infrastructure and
provide a threat analysis for different segments. From a practical point, if
done right, key agreements don't happen that often and should not impact
overall system performance.
There are two reasons for Decru has not been active in trying to get a letter
of assurance for ECC:
a) We are not the authors of 06-449
b) We are not convinced one is necessary...
Hope this helps,
Gideon
________________________________
From: owner-t10 at t10.org on behalf of Matt Ball
Sent: Sun 9/16/2007 5:41 PM
To: t10 at t10.org
Cc: Black_David at emc.com
Subject: Re: More on 128-bit vs. 256-bit security
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 at emc.com <Black_David at emc.com > wrote: 
	* From the T10 Reflector (t10 at t10.org ), posted by:
	* Black_David at 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 at t10.org), posted by:
	> * Black_David at 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 at 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 at t10.org 
-- 
Thanks!
Matt Ball
IEEE SISWG Chair
303-717-2717
http://www.linkedin.com/in/matthewvball 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list