[Cryptography] 256 bit key + 12 digit PIN

[John Denker]

On 01/03/2016 12:26 PM, Ray Dillinger wrote:

> 256-bit encryption it says, but it has buttons for entering
> decimal digits and allows "up to 12-digit pass code combinations
> to protect your data from unauthorized use."

Actually, there is a way in which this "could" make a certain
amount of sense, hypothetically speaking.

Executive summary:  256-bit encryption "could" be used to address
the end-of-life disposal problem.  The PIN serves a different 
purpose.

Key idea:  The threat model contains several different sub-models.

1) Consider the PIN that goes along with a debit card.  If you
 lose the card, the PIN provides some modest protection against
 casual unauthorized use.

 OTOH if you get mugged at the ATM, the mugger will beat the
 PIN out of you.  Making it longer would not help.

 So it is with the PIN on your encrypted disk.  The PIN protects
 against low-grade casual attacks.  It does not protect against
 an Advanced Persistent Threat.  The really bad guys are going
 to beat the PIN out of you, and making it longer would not help.
    http://imgs.xkcd.com/comics/security.png

2) Consider the end-of-life problem.  There are lots of ways the
 disk (SSD or otherwise) could fail in such a way as to make the
 mass storage medium unwriteable.  It might well remain readable,
 especially if the attacker is willing to apply some extra effort.

 If there is full-disk encryption, if you trust the implementation,
 it suffices to destroy the key.  I'm not saying that I trust any
 disk vendors to implement it properly, but let's temporarily and
 hypothetically suppose that they did, as follows:
  *) Each controller is provided with a good HRNG.
  *) On first use, the controller chip generates a unique 256-bit
   salt, and stores it on-chip.
  *) The salt value never leaves the chip.  There is no opportunity
   for the manufacturer to escrow the value.
     -- The chip will however tell you the SHA-256 of the salt, 
      so you can verify that you aren't getting stuck with some 
      standard value.
     -- Better yet, the device will allow you to read the raw
      undecrypted data from the disk, so you can verify that
      it was in fact encrypted.
  *) There is also a way to generate a new salt, in the field,
   using an on-chip HRNG and/or a long string of external data,
   much longer than the PIN.
  *) The salt is combined with the PIN to encrypt the disk.
  *) When it comes time to dispose of the disk, while maintaining
   privacy:
   -- In favorable cases, it suffices to electronically obliterate
    the salt stored on the controller chip.  Easy peasy.
   -- In the unlikely event that it was the controller that failed
   (rather than the mass storage medium), you have to grind away 
   the circuitry from the controller die.  This is easier than
   grinding up all of the mass storage.  Big win.
  *) At this point, the bad guys have nothing to gain by beating
   the PIN out of you.  They may torture you anyway, but you are
   free to lie about the contents of the disk.  When you give up
   the PIN it will not endanger your comrades.

Non-hypothetically speaking, I have zero confidence that disk vendors
(SSD or otherwise) have implemented such a thing correctly.  I can't
even get the Linux folks to implement a decent RNG that would allow
"live CD" images to operate securely.

======================
On 12/26/2015 09:53 PM, Dave Horsfall wrote:

> A good hot flame?  What's the melting point of gold and silicon, anyway?  

Here's a bit more follow-up on that.  I experimented with various methods.

1) Grinding is vastly easier than melting.  Keep in mind that you only
 need to grind away a few microns from the surface;  you don't need to
 annihilate the whole die.

2) If you insist on reducing the whole die to slag, you are better off
 using a combination of modest chemicals plus relatively modest temperatures
 ... rather than exotic chemicals separately or exotic temperatures separately.

At the next level of detail, I discuss various sensible and not-so-sensible
methods of annihilating ICs at
  https://www.av8n.com/security/private-data-storage.htm#sec-annihilate