[FDE] Data at Rest, Data in Transit, and Data in Use
Razdan Khan
rkhan at etisalat.ae
Tue Jul 24 22:32:53 MDT 2007
Can anyone comment on GAK(government access key) when it comes to
Rjindael ?? Is it a myth or does it exist for AES ??
Regards,
Razdan
"Michael Jardine" <michael.jardine at usa.secude.com>
Sent by: fde-bounces at www.xml-dev.com
07/25/2007 06:17 AM
Please respond to
fde at www.xml-dev.com
To
<larry.massey at usa.secude.com>, <fde at www.xml-dev.com>
cc
Subject
Re: [FDE] Data at Rest, Data in Transit, and Data in Use
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
_______________________________________________
FDE mailing list
FDE at www.xml-dev.com
http://www.xml-dev.com/mailman/listinfo/fde
-----------------------------------------
The content of this email together with any attachments, statements
and opinions expressed herein contains information that is private
and confidential, are intended for the named addressee/s only. If
you are not the addressee of this email you may not copy, forward,
disclose or otherwise use it or any part of it in any form
whatsoever. If you have received this message in error, please
notify postmaster at etisalat.ae by email immediately and delete the
message without making any copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.xml-dev.com/pipermail/fde/attachments/20070725/8be8119f/attachment-0001.html
More information about the FDE
mailing list