1.1 (first line) to be added: in magnetic (hard) disk drives.
--- (second line) "... interoperability between different
implementations" There is no interoperability between disk-internal
encrypted devices and external encryption is not best served with this
standard. Instead, I would write something like: for archival purposes,
aiding data recovery from failed disk drives.
--- (second paragraph) "sector-based storage". Here, or somewhere else
we need a definition of 'sector', which is a fixed size block of data
handled by the drive as one unit. Its size is fixed, when the disk is
low-level formatted. Most often used sector sizes are 512, 520 and 4
Kbytes.
--- a) "is be" ?!
--- a)...f) This whole list is unclear. For example: "Resilience against
dictionary attacks". What is checked against a dictionary? The keys or
the plaintext blocks or something else, like the tweak values? How can
someone access the data? How often? Is it going to be detected? End so
on. Without clearing the many ambiguities, this section would not
provide any useful information, but could lead to many
misunderstandings. This block needs a complete re-write and precede it
with a section about the threat model: attack scenarios. Something like
the following.
Attack scenarios
~~~~~~~~~~~~~~~
I. Stolen disk (lost laptop, office break-in)
Data access/modification via
- a. Disk interface
- b. Physical probes on pins on the disk electronics, head signal
- c. Probes on integrated circuit internal lines (irreversible physical
changes = detectable)
- d. Magnetic platters on spin stand (broken seal, irreversible physical
changes = detectable)
II. Periodic inspection of a freshly powered up disk. (Intruder, night
guard, janitor, colleague/visitor in lunch time, etc.)
Data access/modification via
- a. Disk interface
- b. Physical probes on pins on the disk electronics, head signal
Note that, this standard does not intend to protect disk data after a
user has been authenticated and the right keys are transferred to the
encryption engine (viruses, key loggers). Also, data in transit (on
cables or in a network) needs to be protected by other means, like
network security protocols or physical protection of the communication
lines.
Access control
~~~~~~~~~~~~
Access control can be provided by physical means (guard) or
cryptographically, within the hard drive, but it is not the subject of
this standard.
- With access control, only attacks I.c and I.d. could give access to
the encrypted data, but the attack is detectable, therefore only one
snapshot can be made on the encrypted data.
- Without access control, attacks II.a. and II.b. provide many snapshots
to the intruder, which reveal the location of changes of disk data, with
a very good granularity of 16 bytes. It could be a serious leak in
database applications, in the file system structure, etc.
Therefore, LRW-AES as described in the current standard is NOT
recommended if no access control can be provided to the encrypted data.
1.1 Paragraph after a)...f) needs a rework. Parallelizable: OK.
Different keys for every sector: replace with 'one reasonable sized
key' (we don't want questions about different keys for half of the
sectors, do we?). ECB, CBC and Counter modes and many more can be
criticized here - or none of them, but refer to the properties by their
labels: a)...f), not numbers.
--- (4th last paragraph on page 5) "logical position" needs a
definition. One can use 'LBA' as defined in disk standards, or describe
as the index (or address) of the sector, the disk drive uses for access.
LBA is in the range of 0...N-1, if there are N sectors.
--- Append to the text in brackets: 'with the same key'.
--- (2nd last paragraph on page 5) With support for odd length sectors
the last sentence is obsolete.
--- (Last paragraph on page 5) The goal of data decryption in another
device cannot be achieved if the standard is implemented in disk
drives. Raw (encrypted) data cannot be (must not be allowed to be)
moved from one device to another. Reword the second sentence to
reflect, that if data is encrypted by a disk-external implementation of
the standard (not recommended because of the possible traffic analysis),
than other compliant external decryption engines could decrypt the data.
But, this goal is of questionable value. Why do we want to promote an
inherently dangerous use of the standard?
4.1 (Page 9) Just a question: The algorithm as described does not use
the last computed V value and the first XOR is not necessary. Cannot we
optimize the pseudo-code, so this kind of questions won't be raised?
4.2 (Page 9) G is a field defined on bit vectors. It is isomorphic to
GF(2^128), by representing binary polynomials with their coefficient
sequences, that is, using polynomial bases to represent the elements of
GF(2^128). This is all what has to be said. Delete the whole 4.2
section, as it is confusing. There are logical and terminological
inconsistencies. The attempt to prove the correctness of the modular
multiplication algorithm should be replaced by a reference to any
introductory algebra textbook (in section 4.1).
Also, the standard nowhere uses the fact that G is a field, rather than
a ring (nonzero elements have inverses). At least a reference is needed
to a book, where Fields and Rings are defined. And, why do we use this
finite field, at all? There are simple rings, which should work here
better.
Figures 1, and 2. The Galois multiplier block seems to have two outputs,
both marked with T. It would be clearer to connect the horizontal T line
to the vertical part of the other T line, forming a "T" junction ("T"
rotated counterclockwise by 90 degrees).
5.1 (Page 13) Paragraph 1: the requirements that the data consists of an
integral number of cipher blocks is now obsolete.
--- It is unusual to number blocks from 1 to N. Earlier the standard
speaks about logical block indices, which are different. It looks
better to use 0...N-1, and modify the algorithms to increment it as
needed. It is not only more convenient, but the available address field
might be too narrow to represent N.
--- (Second paragraph) the last sentence is obsolete.
--- (Third paragraph, last line) The text allows key scopes to start and
end in the middle of sectors. It is better to prohibit it, because the
LRW_AES algorithms, as described in the standard, are not defined for
changing keys in the middle of the sector. If you do allow unaligned
key scopes, please modify all the algorithms to allow starting and
ending encryption in the middle of the sector. It is not obvious, and
when left undefined it leads to incompatible implementations.
--- (Last paragraph before 5.2) Keep only the first sentence. The
explanation should go to the background section (with more
elaboration), because a vague expression "security vulnerabilities"
does not say anything useful. We ought to know, what they are, if they
can be exploited under our threat model, the attack scenarios.
5.2 (Second paragraph) We cannot define LBA = 1 for the first sector on
the disk, because LBA's are already defined in other standards,
starting from 0. It is better to use base 0 and modify the algorithms
as needed, otherwise you have to call it P1619-LBA, or something else.
--- (Third paragraph) "i = LBA<<n + q". The parameter n is dependent on
the low-level format of the disk, and so the whole LRW-AES. If we don't
choose a large enough universal constant, the transform is dependent on
another parameter: n, and it has to be described as such. It also
means, that hardware implementations cannot hardcode the shift amount,
they have to act differently if the disk is reformatted. It seems to be
an unnecessary complication artificially imposed on the electronics.
Table 4 (Page 15) KeyScopeStrart - Description: Remove "a multiple of 16
and should be".
Table 4 (Page 15) KeyScopeLength - Description: Replace "16" with 'the
sector size', unless you changed all the algorithms to handle key
changes in the middle of a sector.
Laszlo Hars
Seagate Research
