Ping Shaun

[macarró]

If you are still around, I opened a ticket with Securstar that has had
no reply yet, I labelled it as low priority but it was opened two days
ago.

-------------------------------------------------------
Ticket ID: 171465

Hello,

I wanted to know if DriveCrypt Plus Pack has Message Authentication
Code in use on its code.

Thank you for clarification
-----------------------------------------------------
Daiana (Monday, March 16 2009 4:44am)


Hello,
Thank you for your contact!

I will send your question to our developers and will let you know ASAP.

Kind Regards,

-----------------------------------------------------------------

Since you seem to be one of the programmers maybe you know the
answer...

My question is related to a reply I got at sci.crypt, where I asked
people if they thought DCPP was secure, most of the replies are trolls
I would not advice wasting your time reading them, the only good reply
I got is this one:

http://www.derkeiler.com/Newsgroups/sci.crypt/2009-03/msg00114.html

I will sum it up here, so there is no need to read it:

------------------------------
"At the same time they have left out information that is critical to
delivering a good estimation of the actual security. The biggest
omissions I see are that I could find no place where they mention if
there is a Message Authentication Code in use, this is actually very
important to most real-world security situations, and the second big
omission is the lack of discussion of chaining mode.

The biggest concern I have is on
http://www.securstar.com/products_drivecryptpp.php where it says "DCPP
currently works on Windows NT /2000 /2003 /XP and Vista 32 bit (client
and server versions)" this concerns me because full-disk encryption
should be completely operating system indifferent.

While I do not see a reason to say "Don't trust this product," I also
do not see much of anything to inspire my confidence either."

------------------------------

So if you are still around only one question, does DCPP uses Message
Authentication Code?

[John Smith]

Post by macarró
If you are still around, I opened a ticket with Securstar that has had
no reply yet, I labelled it as low priority but it was opened two days ago.
-------------------------------------------------------
Ticket ID: 171465
Hello,
I wanted to know if DriveCrypt Plus Pack has Message Authentication Code
in use on its code.
Thank you for clarification
-----------------------------------------------------
Daiana (Monday, March 16 2009 4:44am)
Hello,
Thank you for your contact!
I will send your question to our developers and will let you know ASAP.
Kind Regards,
-----------------------------------------------------------------
Since you seem to be one of the programmers maybe you know the answer...
My question is related to a reply I got at sci.crypt, where I asked
people if they thought DCPP was secure, most of the replies are trolls I
would not advice wasting your time reading them, the only good reply I
http://www.derkeiler.com/Newsgroups/sci.crypt/2009-03/msg00114.html
------------------------------
"At the same time they have left out information that is critical to
delivering a good estimation of the actual security. The biggest
omissions I see are that I could find no place where they mention if
there is a Message Authentication Code in use, this is actually very
important to most real-world security situations, and the second big
omission is the lack of discussion of chaining mode.
The biggest concern I have is on
http://www.securstar.com/products_drivecryptpp.php where it says "DCPP
currently works on Windows NT /2000 /2003 /XP and Vista 32 bit (client
and server versions)" this concerns me because full-disk encryption
should be completely operating system indifferent.
While I do not see a reason to say "Don't trust this product," I also do
not see much of anything to inspire my confidence either."
------------------------------
So if you are still around only one question, does DCPP uses Message
Authentication Code?

Operating system indifferent? Give me a break, it has to qualify for
what it's going to encrypt........

[Shaun]

To SecurStar support:
Saw this in alt.security.scramdisk
Shaun H.

Post by macarró
If you are still around, I opened a ticket with Securstar that has had
no reply yet, I labelled it as low priority but it was opened two days
ago.
-------------------------------------------------------
Ticket ID: 171465
Hello,
I wanted to know if DriveCrypt Plus Pack has Message Authentication
Code in use on its code.

Interesting question, but the answer is no.

Do you mean MAC use for the encrypted disk area ? I can't think of
any other place it would be useful offhand in a product like DCPP.

The whole of the disk would have to be considered the message, and
creating a MAC for that wouldn't be easy given the random access
nature of the disk volume.

To generate a true MAC for a disk volume, one would therefore have to
read all the disk, everytime any part of it had changed, (to generate
a fresh MAC) and everytime one wanted to check the integrety of the
disk, to calculate what the current MAC should be, for the volume.

Even then one would not know which part of the disk had changed, only
that it wasn't what it should be. IE there was some offline change
there, rendering it invalid.

MACS are usually used to check the integrety of plaintext messages.

I will check why support has not answered this question.

Regards,
Shaun.

[nemo_outis]

Shaun <***@notavalidemailaddress.com> wrote in news:***@4ax.com:

In principle MACs could be done, not for the whole disk, but on a sector by
sector (or clsuter by cluster) basis. The problem is that this "expands"
the amount of info that must be written (the cyphertext PLUS the MAC) and
the OS cannot handle this. The OS just wants to write 512 bytes of data -
whether plain or cypertext - to each sector; there's no room left on a
sector for a sector MAC. Keeping track of the "overflow" for the MAC gets
very messy, very fast if the OS doesn't support it natively.

One good discussion of these issues is:

Security notions for disk encryption
http://eprint.iacr.org/2005/083.pdf

Regards,

[Shaun Hollingworth]

Hi

Agreed. However, even then the disk would have to be scanned, to
detect unauthorised changes somewhere, or errors would have to be
returned when the affected sectors were loaded in by the OS at some
future time, for example when reading a document.

Given that it is not possible to meaninfully change the contents of an
encrypted disk anyway, MAC seems unnecessary, because any changes to
an encrypted disk when it was offline would only show up as garbage
when it was active.

MACs could be used to detect incriminating meaningful which had been
substituted for existing data. But on an encrypted volume it is not
"easily" possible to do that anyway. One can only plant garbage on an
existing encrypted offline disk. Even If one planted plain text, it
would still be garbage when the system was up an running and that
plaintext was "seen" as encrypted data.

It can be fair to assume (provided no one else has the disk's key or
passwords of course) that data which appears correct, on an encrypted
drive ( for example text documents and pictures) won't have been
altered offline by someone trying to plant evidence. Certainly
pictures or incriminating documents could not "easily" be substituted.


Regards,
Shaun.

Post by nemo_outis
In principle MACs could be done, not for the whole disk, but on a sector by
sector (or clsuter by cluster) basis. The problem is that this "expands"
the amount of info that must be written (the cyphertext PLUS the MAC) and
the OS cannot handle this. The OS just wants to write 512 bytes of data -
whether plain or cypertext - to each sector; there's no room left on a
sector for a sector MAC. Keeping track of the "overflow" for the MAC gets
very messy, very fast if the OS doesn't support it natively.
Security notions for disk encryption
http://eprint.iacr.org/2005/083.pdf
Regards,

[Shaun]

On Thu, 19 Mar 2009 18:07:38 +0000, Shaun Hollingworth

Post by Shaun Hollingworth
Hi
Agreed. However, even then the disk would have to be scanned, to
detect unauthorised changes somewhere, or errors would have to be
returned when the affected sectors were loaded in by the OS at some
future time, for example when reading a document.

Drat.

Sorry AGAIN!

I still top posted... It's hard to get out of bad habits. I am so used
to doing that in email, and as I said, I haven't posted much to Usenet
for ages.

I'll get back into it.

Sh.

[nemo_outis]

Shaun Hollingworth <***@noreplyA.com> wrote in news:***@4ax.com:

...

Post by Shaun Hollingworth
Given that it is not possible to meaninfully change the contents of an
encrypted disk anyway, MAC seems unnecessary, because any changes to
an encrypted disk when it was offline would only show up as garbage
when it was active.

I suspect you did not ponder Gjosteen's remarks on "expansion rate" and
"non-malleability" enough.

There are some situations where it is child's play to substitute
particular ciphertext for the current ciphertext on the hard disk and the
decrypted plaintext resulting from the substituted ciphertext will be
perfectly fine and correct, not gibberish.

One example is a "replay attack." I can (under a range of plausible
scenarios where I have frequent access only to the encrypted disk)
substitute an OLDER version of an encrypted file that I harvested some
time back for the current one. This could in some circumstances be a big
problem!

Regards,

[Shaun]

Post by nemo_outis
In principle MACs could be done, not for the whole disk, but on a sector by
sector (or clsuter by cluster) basis. The problem is that this "expands"
the amount of info that must be written (the cyphertext PLUS the MAC) and
the OS cannot handle this. The OS just wants to write 512 bytes of data -
whether plain or cypertext - to each sector; there's no room left on a
sector for a sector MAC. Keeping track of the "overflow" for the MAC gets
very messy, very fast if the OS doesn't support it natively.
Security notions for disk encryption
http://eprint.iacr.org/2005/083.pdf
Regards,

Yes, very interesting stuff.. Thanks for the link BTW.

I am unsure how your idea of a MAC for each sector would resolve this
though, particularly if one shrunk the sector down in size, and stored
the mac along with the sector, or used expanded sectors to store 512
bytes of data, because then a mac for that sector which would be
restored as a single unit along with the data one was trying to
validate! IE: The restoration of old data would also include restoring
the old mac (valid for the old data) as well in this case!!

I guess one would need to store the cluster's mac elsewhere in a table
for disk areas of fixed size,(clusters) and encrypt that table with
the rest of the disk, and make that table was subject to a MAC of its
very own. Then one has to make sure everything is transactional,
otherwise there would be complete paranoia everytime the power plug
was accidently pulled, if one wasn't using UPS or a laptop. Even then
a system bugcheck might cause difficulties. But these are practical
considerations, which have no bearing on the theory.

Replay attacks:

Yes I agree with what you say here. However If one was restoring an
old file to an encrypted medium with the replay attack then one would
not only have to place the restored sectors in the same sector as they
were (otherwise the IVs would be incorrect for the sector and that
would show as data corruption or indeed a complete mess depending how
the IVs etc were deployed) but one might also have to correctly
restore or set up directories, and file allocation tables as well,
which of course, are also encrypted.

I suspect the restoration of a file from long ago on a regularly used
encrypted disk without the keys/passwords would not be as easy to do
undetectably as you think, unless the file had been simply overwritten
with the later version, and not been moved somewhere else on the disk,
in which case restoration to its old position would cause problems.

It might pay to regularly copy sensitive files elsewhere, destroy the
originals and their folders and then wipe the free space, thus
ensuring that other, harder to plant areas of the disk such as
directories and FAT also need restoring too if one is trying to
restore any file to an encrypted disk, offline. without keys or
passwords etc.

Perhaps I might create an option to regularly move specified files
around on the disk!

One other, rather simple option for the paranoid which would be easy
enough to do, and that is simply to store the encrypted disk in a
container file and hash the thing offline, if one was leaving it for a
period or was worried it might be tampered with. When one returned to
it later, one could then take another hash, and make a comparison
before using it again. For smaller containers this would be a doddle I
think to automate. For larger ones patience would be required.

Regards,
Shaun.

[nemo_outis]

...

Post by Shaun
I am unsure how your idea of a MAC for each sector would resolve this
though...

It "resolves" only *some* kinds of attack.

The problem is this: The way DCPP (and all other full-HD OTFE software)
currently encrypts and decrypts there is no such thing (at the encryption
level) as a "wrong" decryption. On, for instance, a sector basis, any
512-byte string is a valid input for decryption and will produce some
corresponding 512-byte plaintext.

Sure, if someone has just randomly tampered with the ciphertext the odds
are astronomically high that the decrypted plaintext will just be
gibberish. But that must be detected and decided OUTSIDE the
encryption/decryption software either by the user personally or by, say,
a software agent (some program he runs to check validity of plaintext).

The encryption/decryption software *cannot* detect tampering by itself -
it has no notion of an "invalid" decryption. Unless, of course, we add a
MAC (or some such) which allows us to detect *some* (but by no means all)
kinds of tampering. The MAC is not the end-all and be-all - it is an
illustration that data integrity requires "expansion" (to use Gjosteen's
term) beyond the bare ciphertext. A strong HD encryption system MUST
HAVE, not just unbreakable ciphertext, but METADATA about that
ciphertext. But this is quite awkward to do which is why may be one
reason Securstar (and your competitors) haven't bothered.

Now some people may not care about this, but they should. After all,
most of your competitors (I couldn't find documentaton regarding your
software) have progressed from ECB, through CBC and LRW, to XTS mode to
protect against attacks as least as obscure and unlikely as the ones I
describe.

Sure the attacks I describe are unlikely for most, but they are feasible
in some not entirely implausible circumstances. Those circumstances, even
if they are pretty unlikely, are trillions and trillions and trillions of
times more likely than a break of the key!

As for the "replay" attack, a MAC is not enough, true. The HD software
must have some additional metadata, a notion of "state" as Gjosteen
explains in several sections of his paper but most succinctly at the
start of section 6.6. He provides the example of an m-ary tree of
checksums.
____________

To give some idea of the dangers of the replay attack, let me describe
one (hopefully not too far-fetched) possibility.

The main danger (as I see it) is not, say, that someone substitutes an
older version of an Excel or Word file - although that could cause
serious problems in some circumstances. No, a bigger danger is binary
files.

Let's imagine that the replay attack substitutes an older version of some
OS dll file, for instance - one that is susceptible to serious exploits
(which a later version fixed). You're now re-exposed to that exploit.

It's not an easy task (and the market of knowledgable users is tiny) but
the first OTFE manufacturer to address these "metadata" issues to further
enhance data security will have a major leg up on the competition - at
least in terms of bragging rights about being cutting edge!

Regards,