Re: open source disk crypto update

[Alexander Klimov]

On Wed, 25 Apr 2007, Travis H. wrote:
> Just recently I discovered Debian default installs now support
> encrypted root (/boot still needs to be decrypted).
>
> Presumably we are moving back the end of the attack surface; with
> encrypted root, one must attack /boot or the BIOS.  What is the
> limit?

The real question is what attacks you are talking about.

For example, protecting confidentiality of /boot and /usr that
contains software that everybody can find on millions of other
computers makes little sense. (OK, your kernel configuration may
be unique, but do you really consider it confidential?)

Do you want encryption to ensure integrity of you software? (Of
course, that would be contrary to common crypto wisdom.) Are you
afraid of attackers secretly changing your software (to monitor
you?) while your computer is off? If so, are you sure that there
is no hardware keylogger in your keyboard and there is no camera
inside a ceiling mounted smoke detector [1]?

In any case, it is a good idea to always start with definition
of the problem and then check if the solution really solves it.
(For example, eve if the problem is that your computer is too
fast, you cannot solve it with encryption :-) )


[1] 

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: More info in my AES128-CBC question

[Alexander Klimov]

On Wed, 25 Apr 2007, Hagai Bar-El wrote:
> It seems as Aram uses a different IV for each message encrypted with
> CBC. I am not sure I see a requirement for randomness here. As far
> as I can tell, this IV can be a simple index number or something as
> predictable, as long as it does not repeat within the same key
> scope.

For CBC mode the IV should be random because it is added
directly to plaintext. For example, if one sends `010' with IV
`001' the result of the xor will be the same as if they
subsequently send `101' with IV `110' and thus an attacker will
be able to learn something about the plaintext. If the IV is
random then we expect a collision after 2^{n/2} messages, but if
IV has some structure (or if an attacker knows the next IV
before they insert their own plaintext to be encrypted) the
probability of collision may become too high.

For some other modes (e.g., CFB, OFB, or CTR) the IV only needs
to be fresh, since the IV is first processed by the cipher. But
even in this case it is a good idea to use random IVs to protect
against state roll-back attacks.

-- 
Regards,
ASK

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: open source disk crypto update

[David Malone]

On Wed, Apr 25, 2007 at 03:32:43PM -0500, Travis H. wrote:
> I think a simple evolution would be to make /boot and/or /root on
> removable media (e.g. CD-ROM or USB drive) so that one could take it
> with you.

Marc Schiesser gave a tutorial at EuroBSDcon 2005 on encrypting the
whole hard drive on your laptop using FreeBSD. If I remember right,
He used the trick of booting from a USB drive. The notes from his
tutorial are here:


http://events.ccc.de/congress/2005/fahrplan/attachments/586-paper_Complete_Hard_Disk_Encryption.pdf

David.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

truncating MACs for confidentiality, was Re: Public key encrypt-then-sign or sign-then-encrypt?

[Travis H.]

One more thing to consider; if you pick a reasonable MAC with twice
the security factor you need, then truncate the output to half the
size, I believe you get both confidentiality and
integrity/authentication guarantees of the desired strength.

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -><- http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpmO9O0IvaLW.pgp
Description: PGP signature

Why CBC? What is wrong with n-bit CFB?

[Travis H.]

I've always wondered this about the lesser-used modes.  What's special
about CBC?

With CFB in particular, I think 8-bit CFB is stupid (one full block
encryption per byte processed - rather computationally expensive), but
n-bit CFB seems just as useful as CBC, if not more so.  Specifically,
I can start sendings bits of C_(i-1) = IV xor P_(i-1) as soon as I
feel like it, even before all of P_(i-1) is in, and it uses the same
number or less crypts than CBC.  Futhermore, it can be used to encrypt
"in place" like CBC but without any special "ciphertext stealing" or
other processing.  Of course I assume that integrity is handled by a
completely seperate mechanism that includes redundancy; anything less
is snake oil.

For that matter, error extension doesn't seem to be an issue to me in
most cases.  Error handling should be done via a seperate layer that
adds redundancy to the ciphertext prior to transmission (and can do
error correction, not just detection).  If any error is so bad that it
defeats this layer, I want to know about it (and will find out via yet
another layer, an integrity/authenticity layer); it could also be a
malicious attack, and unless there is bad sunspot or EMP activity the
seperation of duties allows me to distinguish between the two.  The
exception I can see is if retransmission or delay is unacceptable and
it is better to get a garbled message than none at all.  This may be
the case with human spies in occupied territory, or perhaps for
emergency messages to a deep space probe, or such.  Still, this is the
Internet age and transmission errors are increasingly handled by the
lower layers.  Is anyone actually doing crypto with plaintext that is
interpreted by humans (so they can detect and deal with garbles) over
radio any more?  Not many among us here I suspect.

That having been said, I can't see much in favor of OFB over CTR mode.
-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -><- http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpVkl00SrKY3.pgp
Description: PGP signature

Re: More info in my AES128-CBC question

[Travis H.]

On Wed, Apr 25, 2007 at 05:42:44PM -0500, Nicolas Williams wrote:
> A confounder is an extra block of random plaintext that is prepended to
> a message prior to encryption with a block cipher in CBC (or CTS) mode;
> the resulting extra block of ciphertext must also be sent to the peer.

Not true.  Since we are comparing confounders to IVs, let's make identical
assumptions; that the value is somehow agreed upon in advance.

Then, one need not send it; the receiver can compute C_(i-1) = E_k(confounder)
without actually having it sent to him, and from there
continue decryption with P_i = C_(i-1) xor D_k(C_i) and so on.

> If the
> IV chained across continguous messages as in SSHv2 then you have a
> problem (see above).

I don't fully understand what it means to have IVs chained across
contiguous (?) messages, as in CBC mode each ciphertext block forms
the "IV" of the block after it, effectively; basically an IV is just
C_0 for some stream.

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -><- http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgp5R1OqVH44H.pgp
Description: PGP signature

Re: More info in my AES128-CBC question

[Allen]

Aram Perez wrote:

Another response was "you haven't heard of anyone breaking SD cards have 

you?"

I love responses like this. In the physical world there are the 
examples of the Kyptonite lock and the Master Combination lock. 
By the time you hear about the methodology of the attack someone 
has lost their $16000+ motorcycle or had their wallet with $1000 
and identity papers stolen from their gym locker and they really 
were telling the truth about knowing they locked it up properly.


My counter to this sort of response is, "How many people are 
attacking it that you don't know about yet?"


For one I can almost (not being on staff I can't be absolutely 
sure) guarantee that the NSA is hard at work at cracking SD 
cards. Why, you might ask? Simple. What would be the easiest way 
for a spy to smuggle critical information out of a country? As an 
ostensible tourist with a camera and multiple SD cards. Even 
easier would be to give the camera to a real tourist as a "gift" 
and then steal it back when they get home.


There is a very fine balancing act between confidentiality (or 
secrecy, if you'd rather) and an open society with 
accountability. America's existence is partly as a result of 
people objecting to a "Star Chamber" legal system and yet the 
security of democracy resides on having truly secure and private 
elections that can not be tampered with without it becoming 
known. This is where cryptography can play a critical role in 
maintaining trust in our system of governance and protecting 
people who hold divergent views or beliefs from intimidation.


Best,

Allen

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Public key encrypt-then-sign or sign-then-encrypt?

[Travis H.]

On Wed, Apr 25, 2007 at 03:24:06PM -0300, Mads Rasmussen wrote:
> Hugo Krawczyk [1] showed in the symmetric key setting that the 
> encrypt-then-authenticate was the way to go about securing the integrity 
> of an encrypted message.

Haven't read this yet, but will... and may have comments.

Without reading it, I do have some comments.

At least one authentication protocol failed because it was possible
to strip off a signature then re-use an encrypted blob (e.g. with
one's own signature on it).  So they are malleable.

In _many_ poorly-designed systems it becomes possible to use a system
as a signature oracle to sign arbitrary things.  Smartcards with a
hostile PC are just one of these cases.

One must be very careful what a signature is supposed to attest.

Also there's a semantic issue; am I attesting to the plaintext,
or the ciphertext?  It's possible the difference could be important.

Do we sign letters, or sign envelopes?  If I sign an envelope
containing a letter, I deprive you of much of the evidentiary
value that a signed letter would carry; you cannot easily prove
to someone what I signed without revealing your decryption key(s).

With encrypt-then-authenticate, one can check authentication, and
if it fails, avoid decryption - while in theory this could avoid
DoS, in practice the authentication is more costly than decryption.

In my reading on information-theoretic security, I found that if one
does encryption around the authentication, then one can prevent the
opponent from learning anything about the message.  Specifically, if
Enc(x) is a one-time-pad, then one can use very efficient and
ostensibly unsecure hash functions such as a selection from the
universal hash family ax + b (mod n) for one's integrity and
authentication, and (for certain restrictions on a, b, and n, and
under the assumption of secrecy of a and b) one can have
_information-theoretic security for authentication and integrity_.
That is, no matter how many messages sent, no matter how many CPU
cycles the opponent has available, the opponent can learn nothing new.

I've been discussing and developing a prototype system that aims to
provide information-theoretic security (and at worst, conventional
computational security) for low-bandwidth purposes (i.e. email or IM),
and I will post details here when I have them in a relatively stable
form, for those who are interested.

-- 
Kill dash nine, and its no more CPU time, kill dash nine, and that
process is mine. -><- http://www.subspacefield.org/~travis/>
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpynIGWJie62.pgp
Description: PGP signature