Peter wrote:
Yup. Actually the no-stored-IV encryption was never designed
to be a non- malleable cipher mode, the design goal was to
allow encryption-with-IV without having to explicitly store
an IV. For PWRI it has the additional nice feature of
avoiding collisions when you use a
Peter wrote:
Yup. Actually the no-stored-IV encryption was never designed
to be a non- malleable cipher mode, the design goal was to
allow encryption-with-IV without having to explicitly store
an IV. For PWRI it has the additional nice feature of
avoiding collisions when you use a
Adam Back [EMAIL PROTECTED] writes:
I can see that, but the security of CBC MAC relies on the secrecy of the
ciphertexts leading up to the last block. In the case of the mode you
describe in RFC3211, the ciphertexts are not revealed directly but they are
protected under a mode which has the
On Sat, May 11, 2002 at 04:01:11AM +1200, Peter Gutmann wrote:
| General rant: It's amazing that there doesn't seem to be any published research
| on such a fundamental crypto mechanism, with the result that everyone has to
| invent their own way of doing it, usually badly. We don't even
Adam Back [EMAIL PROTECTED] writes:
I can see that, but the security of CBC MAC relies on the secrecy of the
ciphertexts leading up to the last block. In the case of the mode you
describe in RFC3211, the ciphertexts are not revealed directly but they are
protected under a mode which has the
On Sat, May 11, 2002 at 04:01:11AM +1200, Peter Gutmann wrote:
| General rant: It's amazing that there doesn't seem to be any published research
| on such a fundamental crypto mechanism, with the result that everyone has to
| invent their own way of doing it, usually badly. We don't even
- Original Message -
From: Morlock Elloi [EMAIL PROTECTED]
Collision means same plaintext to the same ciphertext.
Actually all it means in this case is the same ciphertext, since the key is
the same it of course carries back to the plaintext, but that is irrelevant
at this point. The
Title: Re: Re: disk encryption modes
Here is a technique for encrypting a hard disk that should provide reasonable performance, good security, and be easy to render the entire disk unreadable in an emergency.
1. Start with a good (P)RNG. Seed it constantly with radioacitve decay noise
At 01:13 AM 04/29/2002 -0700, [EMAIL PROTECTED] wrote:
[each cluster has 128 bits permanent half-key, 128 bits nonce half-key...]
are for the second cluster, and so on. Each time a disk cluster is
written to, a new temporary half-key is pulled from the (P)RNG and used
to encrypt the
Title: RE: disk encryption modes
With a 4096 byte cluster size, 1 GB of drive space would require 4 MB temporary key file storage. At this ratio, a 128 MB compact flash card could hold a key file for 32 GB of hard drive space. The key file could be stored on the same physical drive if you
Title: Re: Re: disk encryption modes
Here is a technique for encrypting a hard disk that should provide reasonable performance, good security, and be easy to render the entire disk unreadable in an emergency.
1. Start with a good (P)RNG. Seed it constantly with radioacitve decay noise
Title: RE: disk encryption modes
With a 4096 byte cluster size, 1 GB of drive space would require 4 MB temporary key file storage. At this ratio, a 128 MB compact flash card could hold a key file for 32 GB of hard drive space. The key file could be stored on the same physical drive if you
On Mon, Apr 29, 2002 at 11:58:46AM +1200, Peter Gutmann wrote:
Adam Back [EMAIL PROTECTED] writes:
| [RFC3211 mode]
are you sure it's not vulnerable to splicing attacks (swapping
ciphertext blocks around to get a partial plaintext change which
recovers after a block or two)? CBC
Nomen Nescio [EMAIL PROTECTED] writes:
Peter Gutmann and Colin Plumb invented a simple trick which provides this
property in conjunction with CBC or CFB modes. We're going to encrypt/decrypt
a disk block, which is divided into packets which are the cipher block size
(64 or 128 bits). Let P[j]
considering that people notice a matter of 10%, people are going to
Where can we observe those, pray tell ?
Probability of the same plaintext encrypting to the same cyphertext is 1 in
65536.
Which is no where near useful. 1 in 65536 is trivial in cryptographic terms,
Can you provide
I would like to direct anybody's attention who is interested in
transparent drive encryption to GEOM, which will be a native feature of
FreeBSD 5.0.
GEOM is a project that is slated for inclusion in the release of FreeBSD
5.0, a major upgrade to FreeBSD that has been years in the making, due
out
considering that people notice a matter of 10%, people are going to
Where can we observe those, pray tell ?
A great many place, but probably the place it's most easily noticed is on
the freeway (where it's also a matter of speed). When was the last time you
saw a number of people
Adam Back [EMAIL PROTECTED] writes:
So if you mean the approach in 1311 you referenced below:
|Key wrapping:
|
| 1. Encrypt the padded key using the KEK.
|
| 2. Without resetting the IV (that is, using the last ciphertext
| block as the IV), encrypt the encrypted
On Sun, Apr 28, 2002 at 11:11:23AM -0700, Bill Stewart wrote:
The HowTo doesn't say whether or not their crypto filesystem supports swap,
though obviously since you have to input a password to mount the filesystem,
you'd need to have some kind of user interface running before mounting the
The problem with a random IV in disk encryption is that you may not have
anywhere to store it, since you're already using all of your disk space.
Using hash of block number as IV works except that in most encryption
modes, if the first part of the plaintext is unchanged, that part of
the
- Original Message -
From: Adam Back [EMAIL PROTECTED]
On Fri, Apr 26, 2002 at 11:48:11AM -0700, Joseph Ashwood wrote:
From: Bill Stewart [EMAIL PROTECTED]
I've been thinking about a somewhat different but related problem
lately,
which is encrypted disk drives. You could
Joseph Ashwood wrote:
Adam Back Wrote:
This becomes completely redoable (or if you're willing to sacrifice
a small portion of each block you can even explicitly stor ethe IV.
That's typically not practical, not possible, or anyway very
undesirable for performance (two disk hits
- Original Message -
From: Adam Back [EMAIL PROTECTED]
Joseph Ashwood wrote:
Actually I was referring to changing the data portion of the block
from {data} to {IV, data}
Yes I gathered, but this what I was referring to when I said not
possible. The OSes have 512Kbytes ingrained
Title: RE: Re: disk encryption modes (Re: RE: Two ideas for random number generation)
Instead of adding 16 bytes to the size of each sector for sector IV's how about having a separate file (which could be stored on a compact flash card, CDRW or other portable media) that contains the IV's
There's no need to go to great lengths to find a place to store the IV.
An encryption mode that bases the IV on block number and propagates
changes throughout the disk block provides effectively just as much
security. The only theoretical weakness of the latter approach is that
if a block's
There's no need to go to great lengths to find a place to store the IV.
Wouldn't it be much simpler (having in mind the low cost of storage), to simply
append several random bits to the plaintext before ECB encrypton and discard
them upon decryption ?
For, say, 128-bit block cipher and 16-bit
Title: RE: Re: disk encryption modes (Re: RE: Two ideas for random number generation)
- Original Message -
From:
[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 27, 2002 12:11
PM
Subject: CDR: RE: Re: disk encryption
modes (Re: RE: Two ideas
- Original Message -
From: Morlock Elloi [EMAIL PROTECTED]
There's no need to go to great lengths to find a place to store the IV.
Wouldn't it be much simpler (having in mind the low cost of storage), to
simply
append several random bits to the plaintext before ECB encrypton and
On Fri, Apr 26, 2002 at 11:48:11AM -0700, Joseph Ashwood wrote:
From: Bill Stewart [EMAIL PROTECTED]
I've been thinking about a somewhat different but related problem lately,
which is encrypted disk drives. You could encrypt each block of the disk
with a block cypher using the same key
29 matches
Mail list logo
