[FDE] Data at Rest, Data in Transit, and Data in Use
Michael Jardine
michael.jardine at usa.secude.com
Tue Jul 24 20:17:59 MDT 2007
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: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com] On
Behalf Of Larry Massey
Sent: Tuesday, July 24, 2007 5:37 PM
To: fde at www.xml-dev.com
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
larry.massey at usa.secude.com
www.secude.com
|-----Original Message-----
|From: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com]
|On Behalf Of Michael Jardine
|Sent: Tuesday, July 24, 2007 12:20 PM
|To: fde at www.xml-dev.com
|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: fde-bounces at www.xml-dev.com [mailto:fde-bounces at www.xml-dev.com]
|On
|Behalf Of Allen
|Sent: Monday, July 23, 2007 8:44 PM
|To: fde at www.xml-dev.com
|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
| FDE at www.xml-dev.com
| http://www.xml-dev.com/mailman/listinfo/fde
|
|_______________________________________________
|FDE mailing list
|FDE at www.xml-dev.com
|http://www.xml-dev.com/mailman/listinfo/fde
_______________________________________________
FDE mailing list
FDE at www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
More information about the FDE
mailing list