From lower down in this thread:
   
   " Okay, what metric do we apply as a measuring stick for brute
   |   force resistance? Let's use the creation of collisions with one
   |   of the hash functions as a starting point. The figure as I recall
   |     was a space of 2^59 taking 80,000 CPU hours to complete. The
   |   machine was a 256 CPU Itanium super computer in 2005. This works
   |   to to less than 14 days. Given that the same machine could be
   |   constructed with almost 4 times as much power today at a lower
   |   cost, how long will it be before it is realistic to crack 256
   |   bits of key space with machines that could be created in 50 years
   |   by people with even modest budgets?"
   
   
   This refers to processing power.  I am responding to that.
   
   Regards,
   Michael
   ________________________
   Michael Jardine
   SECUDE IT Security - Seattle
   
   -----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Larry Massey
Sent: Tuesday, July 24, 2007 5:37 PM
To: [email protected]
Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use
   
   Michael:
   
   Sorry to inform you, but processing power has nothing to do with
   strengthening a key, that is entirely based on the algorthihm.
   
   Maybe you should check with MK before you put out some of these replies?
   
   Cheers,
   Larry
   
   ___________________________________________________
   Larry Massey
   President
   
   SECUDE IT Security, LLC 
   380 Sundown Drive
   Dawsonville, GA  30534 USA 
   
   Tel : +1 706 216 8609 
   Fax:    +1 706 216 4696
   Mobile : +1 706 215 3854 
   [EMAIL PROTECTED]
   www.secude.com
   
   |-----Original Message-----
   |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   |On Behalf Of Michael Jardine
   |Sent: Tuesday, July 24, 2007 12:20 PM
   |To: [email protected]
   |Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use
   |
   |   Simply put, as processing power increases to decrease the time to
   |crack a
   |key, so can that same processing power be increased to strengthen the
   |key
   |(or algorithm).  So unless something radically changes, the latter will
   |always remain ahead of the former. And yes, you will have to 'roll
   |forward.'
   |The same applies to methods and media for backing up and protecting
   |digital
   |data that you do not want encrypted.
   |
   |
   |   Regards,
   |   Michael Jardine
   |   SECUDE IT Security
   |
   |
   |   -----Original Message-----
   |From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   |On
   |Behalf Of Allen
   |Sent: Monday, July 23, 2007 8:44 PM
   |To: [email protected]
   |Subject: Re: [FDE] Data at Rest, Data in Transit, and Data in Use
   |
   |   Michael Jardine wrote:
   |   >    Pete,
   |   >
   |   >    A brute force attack on an AES-256 encrypted drive that has a
   |STRONG
   |   > "Password" or Key would take years.  Of course, no one could
   |prevent a
   |   > brute-force attack if the attacker gained physical access to the
   |drive
   |in
   |   > question - however if the users password (and thus the key) isn't
   |12345678
   |   > or some other Dilbertian string, then it's realistically impossible
   |to
   |   > retrieve the key in a reasonable time frame.
   |
   |   I'm not raising objections just to be querulous, but rather to
   |   think ahead for possible corner cases which perhaps should be
   |   considered when developing policies.
   |
   |   Okay, we all know Moore Law, right? And we all know that the
   |   needed lifespan for the encryption is based on the value of the
   |   data and the time frame for required protection, Right?
   |
   |   For discussion's sake let's assume that HD life is not an issue
   |   as bit copies will be made and duplicated as long as is needed to
   |   brute force the key. So what kind of data requires long term
   |   protection? Obviously plans for attacking someone need to only
   |   last until after the attack. The same can be said about almost
   |   all business data, be it credit card, billing, marketing, etc.
   |   Yes, these might require 20, even 50 year containment, but that
   |   is still relatively short.
   |
   |   What might need protection for more than 100 years is your DNA
   |   data. These days babies are checked at birth and the code could
   |   reveal information about you - susceptibility to disease and such
   |   - that might be used covertly to discriminate against you in one
   |   way or another. Given that I now regularly see obituaries for
   |   people over 100. Given the propensity to sue, in the US, at the
   |   drop of an imagined injury or defect in disclosure this might
   |   mean that you would have to protect DNA data for the lifespan of
   |   a person plus sometime afterward to prevent suits against the
   |   estate of the person. Add to this that estates seem to last well
   |   beyond the natural lifespan in some cases - the current minor
   |   flap around Kerouac or how the James Joyce and the Bertholt
   |   Brecht estates still attempt to control the use of their literary
   |   works are good examples - and the ability of lawyers in the US to
   |   create lawsuits I can well imagine that 150 years is not totally
   |   unreasonable.
   |
   |   Okay, what metric do we apply as a measuring stick for brute
   |   force resistance? Let's use the creation of collisions with one
   |   of the hash functions as a starting point. The figure as I recall
   |     was a space of 2^59 taking 80,000 CPU hours to complete. The
   |   machine was a 256 CPU Itanium super computer in 2005. This works
   |   to to less than 14 days. Given that the same machine could be
   |   constructed with almost 4 times as much power today at a lower
   |   cost, how long will it be before it is realistic to crack 256
   |   bits of key space with machines that could be created in 50 years
   |   by people with even modest budgets?
   |
   |   Even assuming that Moore's law flattens, the price of CPU
   |   horsepower does not decline at the rate it has in the last
   |   several years, no new time v. effort approaches are thought of or
   |   other algorithmic attacks created, it is highly unlikely that the
   |   current AES-256 standard would last that long. Given this there
   |   are only two ways to protect your data, keep rolling the
   |   encryption standard and pray that a copy with a weaker key does
   |   not exist, or destruction of the data. Given human fallibility I
   |   think the choice is obvious - destruction once the need for
   |   access to the data has ended no matter how long that is.
   |
   |   Yes, this is a corner case that is highly unlikely to ever
   |   happen, but things happen. Look at D.B. Cooper and the 727 exit
   |   X. Who would have ever thought you could parachute from a jet and
   |   survive? While we don't know if he did survive, we do know that
   |   five months later Richard Floyd McCoy, Jr., using the name James
   |   Johnson, hijacked United Airlines Flight 855 and also parachuted
   |   into the night from its rear stairs with half a million dollars.
   |   Yes, McCoy was caught and convicted in federal court in June of
   |   1972 in Salt Lake City, Utah.
   |
   |   So you can see there are more possibilities than we have the
   |   vision to foresee, so I suggest that we just destroy the data
   |   *and* the key.
   |
   |
   |   Best,
   |
   |   Allen
   |
   |   _______________________________________________
   |   FDE mailing list
   |   [email protected]
   |   http://www.xml-dev.com/mailman/listinfo/fde
   |
   |_______________________________________________
   |FDE mailing list
   |[email protected]
   |http://www.xml-dev.com/mailman/listinfo/fde
   
   
   _______________________________________________
   FDE mailing list
   [email protected]
   http://www.xml-dev.com/mailman/listinfo/fde


_______________________________________________
FDE mailing list
[email protected]
http://www.xml-dev.com/mailman/listinfo/fde

Reply via email to