Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?

2004-09-05 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], David Kreil writes:

 On a modern disk there is no sequence of writes that will guarantee
 you that your data is iretriveable lost.
 Even if you rewrite a thousand times, you cannot guard yourself against
 the sector being replaced by a bad block spare after the first write.

Good point. In the rare chance event that this happens, it would indeed be bad 
news as an attacker would then only have to scan the bad blocks for possible 
copies of the key.

He still has no way of recognizing the key though...

A simple improvement on the present situation would already be if
the keys were not overwritten with zeros but with random bits. I
don't know how difficult it would be to attempt to physically write
random bits multiple times but it would much strengthen the feature
apart from the rare cases when the sectors of the masterkey have
been remapped into bad blocks.

Please read the paper, there is a reason why it is zero bits.

What do you think? Is the required effort disproportional to the
intended value of the blackening feature?

Blackening adds no significant incremental security imo, on the
other hand it is feasible to implement it, so I've put it on the
todo list.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?

2004-09-05 Thread David Kreil

Dear Poul-Henning,

  On a modern disk there is no sequence of writes that will guarantee
  you that your data is iretriveable lost.
  Even if you rewrite a thousand times, you cannot guard yourself against
  the sector being replaced by a bad block spare after the first write.
 
 Good point. In the rare chance event that this happens, it would indeed be
 bad 
 news as an attacker would then only have to scan the bad blocks for possible 
 copies of the key.
 
 He still has no way of recognizing the key though...

Right, he'd have to try them all.

 A simple improvement on the present situation would already be if
 the keys were not overwritten with zeros but with random bits. I
 don't know how difficult it would be to attempt to physically write
 random bits multiple times but it would much strengthen the feature
 apart from the rare cases when the sectors of the masterkey have
 been remapped into bad blocks.
 
 Please read the paper, there is a reason why it is zero bits.

Sorry, forgot.

 What do you think? Is the required effort disproportional to the
 intended value of the blackening feature?
 
 Blackening adds no significant incremental security imo,

From a security point of vie, yes. From a social/civil-liberties/legal point 
of view, I felt it was an excellent thing to have.

 on the
 other hand it is feasible to implement it, so I've put it on the
 todo list.

That's great, thanks a lot!

With best regards,

David.



Dr David Philip Kreil (`-''-/).___..--''`-._
Research Fellow`6_ 6  )   `-.  ( ).`-.__.`)
University of Cambridge(_Y_.)'  ._   )  `._ `. ``-..-'
++44 1223 764107, fax 333992 _..`--'_..-_/  /--'_.' ,'
www.inference.phy.cam.ac.uk/dpk20   (il),-''  (li),'  ((!.-'


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?

2004-09-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], David Kreil writes:

Hi,

From what I can see so far, they are simply overwritten with zeros - is that 
right? If so, the blackening feature would be much weakend, as once can read 
up to 20 layers of data even under random data (and more under zeros). I would 
be most grateful for comments, or suggestions of where/how one could extend 
the code to do a secure wip of the key areas. Also, I know practically nothing 
of how I could to best get FreeBSD to physically write to disk 
(configurability of hardware cache etc permitting).

On a modern disk there is no sequence of writes that will guarantee
you that your data is iretriveable lost.

Even if you rewrite a thousand times, you cannot guard yourself against
the sector being replaced by a bad block spare after the first write.

If your threat-analysis indicates this is a serious threat for you,
you should arrange for simple physical destruction of your disk to
be available.

Most modern disks have one or more holes in the metal only covered
by a metalic sticker.  Pouring sulfuric acid through those openings
is a good start.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?

2004-09-04 Thread David Kreil

Dear Poul-Henning,

Thank you very much for your comments!

 From what I can see so far, they are simply overwritten with zeros - is
 that 
 right? If so, the blackening feature would be much weakend, as one can read 
 up to 20 layers of data even under random data (and more under zeros).
 I would 
 be most grateful for comments, or suggestions of where/how one could extend 
 the code to do a secure wipe of the key areas. Also, I know practically
 nothing 
 of how I could to best get FreeBSD to physically write to disk 
 (configurability of hardware cache etc permitting).
 
 On a modern disk there is no sequence of writes that will guarantee
 you that your data is iretriveable lost.
 Even if you rewrite a thousand times, you cannot guard yourself against
 the sector being replaced by a bad block spare after the first write.

Good point. In the rare chance event that this happens, it would indeed be bad 
news as an attacker would then only have to scan the bad blocks for possible 
copies of the key.

 If your threat-analysis indicates this is a serious threat for you,
 you should arrange for simple physical destruction of your disk to
 be available.
 
 Most modern disks have one or more holes in the metal only covered
 by a metalic sticker.  Pouring sulfuric acid through those openings
 is a good start.

Hmm... to me, the main benefit of the blackening feature would seem to be the 
possibility of compliance with a court directive without disclosing confidential data. 
With multiple key holders, any particular person can maintain that they have done all 
they could to comply. Not only is the optics of having your disks are found in vats of 
sulfuric acid rather bad, it's also more unlikely that a moment of opportunity 
arises.

A simple improvement on the present situation would already be if the keys were not 
overwritten with zeros but with random bits. I don't know how difficult it would be to 
attempt to physically write random bits multiple times but it would much strengthen 
the feature apart from the rare cases when the sectors of the masterkey have been 
remapped into bad blocks.

As rightly pointed out in the manpages, the better the encryption gets, the more 
likely are attacks via other routes. Reading a few layers of the current masterkey 
location + all bad blocks with an MFM should cost no more than a few thousand $.

What do you think? Is the required effort disproportional to the intended value of the 
blackening feature?

With many thanks again for your help

and best regards,

David.



Dr David Philip Kreil (`-''-/).___..--''`-._
Research Fellow`6_ 6  )   `-.  ( ).`-.__.`)
University of Cambridge(_Y_.)'  ._   )  `._ `. ``-..-'
++44 1223 764107, fax 333992 _..`--'_..-_/  /--'_.' ,'
www.inference.phy.cam.ac.uk/dpk20   (il),-''  (li),'  ((!.-'


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?

2004-09-03 Thread David Kreil

Hi,

From what I can see so far, they are simply overwritten with zeros - is that 
right? If so, the blackening feature would be much weakend, as once can read 
up to 20 layers of data even under random data (and more under zeros). I would 
be most grateful for comments, or suggestions of where/how one could extend 
the code to do a secure wip of the key areas. Also, I know practically nothing 
of how I could to best get FreeBSD to physically write to disk 
(configurability of hardware cache etc permitting).

With best regards,

David.

 
 Hello,
 
 I was wondering whether someone knowledgable about gbde internals could tell 
 me how the keys are being destroyed on request under the blackening feature. 
 Ideally, I'd like them to be overwritten with random data at least 20 times 
 independently, but I suspect it may well be done in a different way. I'd be 
 grateful for learning how the blackening works (and why!).
 
 With many thanks for your help in advance,
 
 David Kreil.
 


Dr David Philip Kreil (`-''-/).___..--''`-._
Research Fellow`6_ 6  )   `-.  ( ).`-.__.`)
University of Cambridge(_Y_.)'  ._   )  `._ `. ``-..-'
++44 1223 764107, fax 333992 _..`--'_..-_/  /--'_.' ,'
www.inference.phy.cam.ac.uk/dpk20   (il),-''  (li),'  ((!.-'


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?

2004-09-03 Thread Len Zettel
On Friday 03 September 2004 07:18 pm, David Kreil wrote:
 Dear Vijay,

  I guess I took this off the list. It's OT, in my oppinion.

 Oh. Anywhere more appropriate to send it to that you could suggest at all?
 Now also trying freebsd-geom - would that have been the better place to
 send this to to start with?

  I don't know much of anything about data recovery. But, if you can
  recover data under 20 layers of random writes or 20 iterations of 0s,
  then how *can* you wipe a hard drive? Short, preferably, of setting fire
  to it :D

While i am not an expert in this area, I can not help but wonder---
Who are you worried about recovering the data, under what
circumstances?  My best guess is that recovering anything from
even _one_ data over-write is going to require that the recoverer have
physical posession of the drive and very sophisticated equipment
indeed.  That means they have to be some branch of a govermnment.
If you are going to attract attention of that caliber there are likely a lot
of other easier means of finding out what you are up to.  Otherwise, a
good hot fire ought to be pretty final even for the CIA.
   -LenZ-
 Sigh, tricky, yes. Apparently wiping with 20 repeats of random noise does
 the trick (say from /dev/random or arc4random generated). The difficulty
 with modern file systems / operating systems / disk drives is actually
 getting the patterns written to the magnetic media.

 I'm writing to the list because both assessing whether there really is a
 risk and how to fix it requires quite a bot of knowledge that I lack, like
 knowing where to look in the gbde code (maybe I misunderstood?), or writing
 code that is disk driver/hardware caching aware and can hence force a
 flush.

 I'd be most grateful for any help or suggestions.

 With best regards,

 David.

   Hi,
  
   From what I can see so far, they are simply overwritten with zeros -
   is that
  
   right? If so, the blackening feature would be much weakend, as once can
   read
   up to 20 layers of data even under random data (and more under zeros).
   I would
   be most grateful for comments, or suggestions of where/how one could
   extend
   the code to do a secure wip of the key areas. Also, I know practically
   nothing
   of how I could to best get FreeBSD to physically write to disk
   (configurability of hardware cache etc permitting).
  
   With best regards,
  
   David.
  
   Hello,
  
   I was wondering whether someone knowledgable about gbde internals
   could tell
   me how the keys are being destroyed on request under the blackening
   feature.
   Ideally, I'd like them to be overwritten with random data at least 20
   times
   independently, but I suspect it may well be done in a different way.
   I'd be
   grateful for learning how the blackening works (and why!).
  
   With many thanks for your help in advance,
  
   David Kreil.
  
   ---
  - Dr David Philip Kreil (`-''-/).___..--''`-._
   Research Fellow`6_ 6  )   `-.  ( ).`-.__.`)
   University of Cambridge(_Y_.)'  ._   )  `._ `. ``-..-'
   ++44 1223 764107, fax 333992 _..`--'_..-_/  /--'_.' ,'
   www.inference.phy.cam.ac.uk/dpk20   (il),-''  (li),'  ((!.-'
  
  
   ___
   [EMAIL PROTECTED] mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-questions
   To unsubscribe, send any mail to
   [EMAIL PROTECTED]
 
  --
  Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

 
 Dr David Philip Kreil (`-''-/).___..--''`-._
 Research Fellow`6_ 6  )   `-.  ( ).`-.__.`)
 University of Cambridge(_Y_.)'  ._   )  `._ `. ``-..-'
 ++44 1223 764107, fax 333992 _..`--'_..-_/  /--'_.' ,'
 www.inference.phy.cam.ac.uk/dpk20   (il),-''  (li),'  ((!.-'


 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to
 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gbde blackening feature - how can on disk keys be destroyed thoroughly?

2004-09-03 Thread Vijay Kaul
On Fri, 03 Sep 2004 19:41:18 -0400, Len Zettel [EMAIL PROTECTED] wrote:
snip
While i am not an expert in this area, I can not help but wonder---
Who are you worried about recovering the data, under what
circumstances?  My best guess is that recovering anything from
even _one_ data over-write is going to require that the recoverer have
physical posession of the drive and very sophisticated equipment
indeed.  That means they have to be some branch of a govermnment.
If you are going to attract attention of that caliber there are likely a  
lot
of other easier means of finding out what you are up to.  Otherwise, a
good hot fire ought to be pretty final even for the CIA.
   -LenZ-
I used to work in a lab and a co-worker had be a submarier for the US. He  
said that one of their projects was to figure out how to best destroy CDs  
for the government. Supposedly the CDs were recoverable even after  
cross-shredding. They either decided that melting them over a heatsink  
(coffee mug) in a microwave (also makes a nice ash tray) or going at them  
with an acetaline torch was the final solution.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: gbde blackening feature - how can on-disk keys be destroyed thoroughly?

2004-09-03 Thread David Kreil

Dear LenZ,

 Who are you worried about recovering the data, under what circumstances?

The value of the blackening feature should be that you can give away the drive 
and your password, say, under pressure by the [court|mafia|whoever], without 
compromising any confidential information on the drive.

 My best guess is that recovering anything from
 even _one_ data over-write is going to require that the recoverer have
 physical posession of the drive and very sophisticated equipment
 indeed.  That means they have to be some branch of a govermnment.

Hmm, I much doubt that. True, you need a clean room and a magnetic force 
microscope. Even standard data recovery firms like www.dataclinic.co.uk, 
however, can recover data under up to 8 overwrites. (NB: No affiliation or 
recommendation there.)

Government agencies can go deeper (20x or possibly more but it gets 
increasingly more difficult).

 If you are going to attract attention of that caliber there are likely a lot
 of other easier means of finding out what you are up to.

Sure, like pointing an antenna at my computer while its running ;-)

I guess my main point is: If there is a blackening feature which is designed 
to give users peace of mind about disclosing their password under pressure, 
and it is known that data can be recovered underneath simple overwrites for a 
pack of $$ but that writing a random pattern, say 30x, makes the delete safe, 
I'd much argue in favour of doing the latter. As the areas are small, this 
should be really quick, too. The problem is getting the multiple overwrites 
out to the magnetic media, rather than them sitting somewhere in a cache 
buffer in computer or drive memory.

 Otherwise, a good hot fire ought to be pretty final even for the CIA.

Actually, the above firm specializes in Track 0 damage, fire damage, flood 
damage, impact damage and overwritten data...

So, if a commercial enterprise can offer this, I don't think I'm unduly 
concerned. Depending on the country, dissolving the magnetic layer in acid or 
finely grinding it off are considered final for classified materials.

Now, I'm not interested in an exercise of extreme paranoia. If overwritten keys can, 
however, easily be recovered then I'd consider this a relative weakness compared to 
all the sophisticated effort that has gone into the design of gbde and its encryption 
algorithms.

My question hence remains, can someone more knowledgable than me maybe comment on 
whether I have misunderstood what gbde does, or else how the strength of the 
blackening could please be improved (i.e., how to do a 30x random wipe bypassing cache 
in a hardware independent manner)?

With best regards,

David.



Dr David Philip Kreil (`-''-/).___..--''`-._
Research Fellow`6_ 6  )   `-.  ( ).`-.__.`)
University of Cambridge(_Y_.)'  ._   )  `._ `. ``-..-'
++44 1223 764107, fax 333992 _..`--'_..-_/  /--'_.' ,'
www.inference.phy.cam.ac.uk/dpk20   (il),-''  (li),'  ((!.-'


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]