On whitening, IV Values
sio...@my-deja.com
values? I know it is in the first sector; but how are they generated,
and how are they used for encrypting/decryption other sectors?
Sent via Deja.com http://www.deja.com/
Before you buy.
Shaun Hollingworth
>Can someone explain to me how Scramdisk implents IV and whitening
>values? I know it is in the first sector; but how are they generated,
>and how are they used for encrypting/decryption other sectors?
>
The IV table consists of 64 x 128 bit randomly chosen values... this
can be considered as a group of 2 x 32 x 128 bits... (1O24 bytes)
and this IV table is stored encrypted on the disk.. with the hash key
of the password, in the header, preceding the cipher key, which is
also stored encrypted with the hask key. Everything else needs the
deciphered version of this data, INCLUDING the IVs etc...
Scramdisk IVs currently supports 2^32 (4 billion) sectors of 512 bytes
per sector... (2 billion kilobytes therefore) and the IV is chosen as
follows:
Set a 128 bit value to zero called x
Loop:
Set a pointer to the start of the IV table:
Take the least significant bit of the sector number. If the bit is
zero, select the first (even) 128 bit value. If it is one, select the
second 128 bit value. add this to x (which is initially 0)
(yes I know Xor could have been used too)
Shift the sector number right, Move the pointer to the IV table on by
256 bits (32 bytes)
Go back to Loop until all 32 bits have been used and the pointer is
at the end of the IV table.
In this way, for each sector we generate a (extremely likely to be)
unique 128 bit value for every single possible disk sector, because
for each 32 bit pattern in a sector number, a different set of values
is summed up. Just one selection being different, will make ALL the
difference to the outcome..
The 128 resultant value x is then split up into a 64 bit IV and a 64
bit prewhitening value.. used in the cipher loop.
This ensures that every sector of every disk is vastly different, even
though the passwords and data might be identical for many disks.
Which is whyn you should create them all individually.
On encryption the 64 bit (32 ivl bits, 32 ivr bits) initial value is
applied as follows:
buffer[n]=ivl^buffer[n];
buffer[n+1]=ivr^buffer[n+1];
// Here we call the appropriate cipher:
ivl=buffer[n]; // chain IVs for next pass IV is
ivr=buffer[n+1] // now result of encipherd (data^ IV)
buffer[n]^=cbccl; // every 64 bit value sent to disk, now has
buffer[n+1]^=cbccr; // pre-whiteing constant (for this sector)
// applied before being sent to disk.
// On 128 bit ciphers it is every other 64 bit
// value, which will still obfuscate every 128
//bit value passed into the cipher.
Shaun.
sio...@my-deja.com
To see if I understood you right, lemme change your implentation to
support 128bit Ciphers like Rijndael.
1)
IV table now has 2 x 32 x 256 bits ('2' - we need IV & Whitening
values, '32' - to support 2^32 sectors, i.e. sector number is in
dword, '256' because IV and Whitening values are both 128bit now).
Total size of randomly chosen table is now 2048 bytes, i.e. 4 sectors
of size 512 bytes.
2)
Hash user key, cipher key don't change.
3)
Set a 256bit value to zero called x
Loop:
Set a pointer to the start of the IV table:
Take the least significant bit of the sector number. If the bit is
zero, select the first (even) 256 bit value. If it is one, select the
second 256 bit value. add this to x (which is initially 0).
Shift the sector number right, Move the pointer to the IV table on by
512 bits (64 bytes).
Go back to Loop until all 32 bits have been used and the pointer is
at the end of the IV table.
The 256 resultant value x is then split up into a 128bit IV and a
128bit prewhitening value.. used in the cipher loop.
Greets.
Shaun Hollingworth
>Thanks for the quick reply, Shaun.
>To see if I understood you right, lemme change your implentation to
>support 128bit Ciphers like Rijndael.
>
Although your modifications appeared to be perfecty correct,
It is not really necessary to implement them:
If you have 128 bits to be passed to a 128 bit cipher, and change only
64 of those 128 bits using an IV, you are still modifying the outcome
of the cipher's result (IE all 128 bits of output) in a possible
(4_Billion x 4_Billion) different ways and this was the approach taken
when the 128 bit Square cipher was implemented in Scramdisk.
IE - On Square, the IVs change just the low 64 bits of the 128 bit
input to cipher (before encryption...) IVs *don't* not have to be the
same number of bits, as the cipher itself handles in one single
"gulp".. All 128 bits of output from the ciper WILL however be
influenced by the IV 64 bit value...
The purpose of IVs and CBC is to make data which would otherwise look
identical after encryption (because the input data was also identical)
look very different.
Similarly the pre-whitening values applied only to the low 64 bits of
the result of an 128 bit enciphering operation (IE *after*
encryption) will drastically modify the outcome of the resultant
pattern (4billion x 4billion), on later decryption if they are
incorrect, and of course all the values decrypted in a sector, will be
incorrect unless the correct Pre-Whitening value is determined before
decryption of the data.
It should be clearly noticed, that an incorrect value, of IV or
Pre-whitening will influences the possibe state of ALL 128 bits of
the result of each call to the 128 bit cipher, not just the low 64
bits... which are initially modified in the input to it.
Regards,
Shaun.