W3C home > Mailing lists > Public > public-wsc-wg@w3.org > November 2007

RE: ACTION-335 logotypes and ISSUE-96 discussion

From: <michael.mccormick@wellsfargo.com>
Date: Mon, 19 Nov 2007 15:23:25 -0600
Message-ID: <9D471E876696BE4DA103E939AE64164D7CD3EC@msgswbmnmsp17.wellsfargo.com>
To: <pbaker@verisign.com>, <dan.schutzer@fstc.org>, <Mary_Ellen_Zurko@notesdev.ibm.com>
Cc: <public-wsc-wg@w3.org>
I think it depends on the application/adversary you have in mind.
Hiding information from a well funded government requires different
crypto (or at least key lengths) than garden variety hacking, fraud, or
corporate espionage.  NIST guidelines are 100% adequate for the garden
variety stuff.

  _____  

From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org]
On Behalf Of Hallam-Baker, Phillip
Sent: Monday, November 19, 2007 10:11 AM
To: Dan Schutzer; Mary Ellen Zurko
Cc: W3C WSC Public
Subject: RE: ACTION-335 logotypes and ISSUE-96 discussion


Modern crypto is for almost all purposes 100% effective. We have issues
today due to legacy deliberately weakened crypto (40bit) and use of DES
- a three decades old standard from 1975.
 
We are currently phasing out SHA-1 because we are not confident of its
effectiveness past 2025 or so. We are about to complete the phase out of
RSA 1024 which is probably good till at least 2015.
 
With symmetric algorithms we are incredibly conservative because we can
afford to be. Using the strongest available crypto does not add to the
processing overhead markedly versus weak crypto.
 
With asymmetric algorithms there is a processing overhead and there is a
possible issue with RSA 2048 in 2025 or so. Now if we were any other
part of the computing world we would simply wait till three years before
disaster strikes and then get everyone to panic like the COBOL jockeys
did during Y2K or as they called it 'the pension fund'.
 
 
Security engineering is different. We obsess about the stuff we can
control because there is so much that we either can't or don't know how
to control.


  _____  

	From: Dan Schutzer [mailto:dan.schutzer@fstc.org] 
	Sent: Saturday, November 17, 2007 7:08 AM
	To: 'Mary Ellen Zurko'; Hallam-Baker, Phillip
	Cc: 'W3C WSC Public'
	Subject: RE: ACTION-335 logotypes and ISSUE-96 discussion
	
	

	Funny I thought crypto was not 100% effective, which is why
crypto length codes and algorithms have to be upgraded from time to
time. Its all about making the processing power necessary to
exhaustively search through all possibilities computationally infeasible
with today's computer power. As the computer power increases, the crypto
needs to be stepped up.

	 

	
  _____  


	From: public-wsc-wg-request@w3.org
[mailto:public-wsc-wg-request@w3.org] On Behalf Of Mary Ellen Zurko
	Sent: Friday, November 16, 2007 12:27 PM
	To: pbaker@verisign.com
	Cc: W3C WSC Public
	Subject: RE: ACTION-335 logotypes and ISSUE-96 discussion

	 

	
	I will indulge in a rathole, in part, because I do think it
represents an important philosophical category for WSC participants, so
that being explicit about it and airing it will be a good thing long
term for discussions and consensus. 
	
	> The reason that we tend to obsess at 100% is that cryptography

	> allows us to be pretty good at some aspects of technical
security. 
	
	I have another view about why 100% is important to some security
people. It's because, in security, anything less than 100% represents
the opportunity for attack. It is a vulnerability. Security people
naturally don't want vulnerabilities,and particularly don't want to be
responsible for any vulnerabilities. Even if the action they take
represents, as you put it, a risk reduction. It can be difficult, both
personally and organizationally, to be proud of and promote the risk
reduction, while bearing the responsibility for some of the subsequent
risk. And that's even if you're lucky enough to be able to articulate
the risk reduction clearly. Not that you've got a hope of being able to
actually prove it. 
	
	
Received on Monday, 19 November 2007 21:24:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:53 GMT