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
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 have
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 th
- 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. T
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
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 cl
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
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 encry
> > > 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
> 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 pro
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). Le
- 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
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 for
> 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
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 conte
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&
- 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
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 dis
- 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.
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 ciphertex
Right, it sounds like the same approach I alluded to, except I didn't
use a salt -- I just used a fast pseudon random number generator to
make the IV less structured than using the block number directly.
I did some experiments with a used disk and found that if you use the
block number directly f
> You could encrypt twice (CBC in each direction or something), but that
> will again slow you down by a factor of 2.
You can't easily get away with storing the IV as multiple parts of the IO
pipe like to see blocks in 2^n form.
The approach I take in Rubberhose is to calculate the IV from a
ve
22 matches
Mail list logo
