| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Thank you very much. It is very helpful. Boaz From: Joachim Schneider
[mailto:Joachim.Schneider@UTIMACO.DE]
Q:
"The relation between "data-unit" and "key-scope": The
mapping between data unit and a key is one to one, or some data-units can be
encrypted with the same key?" A:
A key scope would normally apply to more than one data unit. In fact, section
3.1.1 implies that it's more than one. Although you *could* define key scope ==
one data unit if you really wanted. Q:
"What is the typical size of such a data unit? I understand it is outside
the scope of this work, but you probably have a size in mind. Is that a disk
sector?" A:
It would make a lot of sense to use a sector's worth of data as your data unit,
or maybe a file system cluster's worth if you're encrypting a file. For
arbitrary data streams on other types of media there may be other sizes that
are useful in a particular situation. Q:
"-In line 30 and 31 page 3 there is statement says that the size of a
data-unit is 2^128-2 128 bit block. On the next sentence it says that the size
of the data-unit is 2^20 128 bit block. This seems to be a contradiction."
A:
I think the key is in the words preceding the numbers - namely "shall
not" (meaning may not without grave consequences) and "should
not" which isn't quite as restrictive. No contradiction there. Q:
" j, the index of the 128 bit block within a data-unit starts from 0 or 1
(i.e. the first 128 bit block of P is xored with AES(i) or with
AES(i)*ALFA?)" A:
The code in Annex 3 suggests that j starts from 0, as the first multiplication
with alpha happens *after* XORing the tweak to the first plaintext / ciphertext
blocks. Q:
"Since I (tweak value), Key1, Key2, are constant for a given data-unit,
and j is sequentially incremented, it seems that within a certain data-unit it
is enough to multiply each T by ALFA in order to get the next T. Is that
correct? (i.e. T(n+1) = T(n)*ALFA ) " A:
Right. That's exactly what the example code in Annex 3 does. Q:
" In the formula: Cq
← 1 XTS-AES-blockEnc(Key,
Pj, i, q) Pj can be replaced by Pq, correct?" A:
I think you're right. Any C(q) would be derived from a P(q) and the tweak. I
think j is a typo and should be replaced with q as j is a loop invariant. Same
goes for the decryption formula on page 7. Please
respond to Matt Ball <matt.ball@IEEE.ORG> To: STDS-P1619@LISTSERV.IEEE.ORG Thanks.
So
I read the draft (P1619-D19), and the following questions occurred to me:
(All
questions refer to IEEE
P1619/D197, July
October 2007) -The
relation between "data-unit" and "key-scope": The mapping
between data unit and a key is one to one, or some data-units can be encrypted
with the same key? -What
is the typical size of such a data unit? I understand it is outside the scope
of this work, but you probably have a size in mind. Is that a disk sector?
-In
line 30 and 31 page 3 there is statement says that the size of a data-unit is
2^128-2 128 bit block. On the next sentence it says that the size of the
data-unit is 2^20 128 bit block. This seems to be a contradiction. -
j, the index of the 128 bit block within a data-unit starts from 0 or 1 (i.e.
the first 128 bit block of P is xored with AES(i) or with AES(i)*ALFA?)
-Since
I (tweak value), Key1, Key2, are constant for a given data-unit, and j is
sequentially incremented, it seems that within a certain data-unit it is enough
to multiply each T by ALFA in order to get the next T. Is that correct? (i.e.
T(n+1) = T(n)*ALFA ) -
In the formula: Cq
← 1 XTS-AES-blockEnc(Key,
Pj, i, q) Pj can be replaced by Pq, correct?
Thanks
for your help, and best regards, Boaz
|