The standard is what the standard is. These words are from the PAR which is our charter. No more, no less. These words are at
Note that the words "spinning", "magnetic", "hard", or "disk" do not appear anywhere in this statement (or this entire document for that matter).
I am sorry, but this is not the case. if optical, solid state, magneto optical, electrostatic, organic, printed, tape are organized in a manner that can be considered "sector based", then this applies. This terminology comes from a document called the PAR which is the authorization to do this work. This authorization is what it is we told the mother organization (IEEE-SA) that we are doing.
Another (future) task that we can complete is the a CC protection profile for people that claim conformance with this standard. This is a place where many other security issues can be discussed. After we have the base algorithm in place, then the organization can move on to the CC profile. The process is what it is. We can not put everything in one document or it would never be done.
There are over 100 people on this reflector. Your emails are being read.
[disk-internal encryptions] legitimate for you to have this viewpoint
The point I made several times is that we have to establish a threat
model. I proposed something: theft and periodic inspection. Nobody
argued with that, nothing was suggested to add or remove. Therefore,
you all seemed to agree, that data inspection and traffic analysis is a
threat. To prevent that, access control is needed, because LRW-AES is
weak in this regard.
Therefore, without (physical, crypto, logistic...) access control to the
raw data LRW-AES is not to be recommended. Do you agree? If not, we have
to discuss this point. If yes:
How do you provide physical, logistic access control? It is expensive,
clumsy and consequently it will never be a mass market. These are what
I considered less important applications, because in these situations
you don't even need data encryption: the guard providing access control
also protects the data, or, the data is not vulnerable to traffic
analysis, what you cannot tell for sure. What remained is cryptographic
access control to the raw (encrypted) data. It can only be provided in
the disk drive itself, which also makes logical that the next step, the
encryption, to be implemented in the disk drive, too.
I explained these earlier, also in the December meeting and in several
of my emails. Up to now, nobody raised an argument, so I assumed we all
agreed on this point.
We are not in the business of evaluating which technology is best suited for "secure storage"
We provide a tool, and it is natural to tell what it is good for and in
what cases others are better. Without it, at the first successful
attack against a P1619 encrypted storage device the whole standard
looses credibility, and we should feel responsible to the damage, not
having provided a warning to our best knowledge. If all the
implementers were crypto experts, you could say that they should have
assessed the risks, but they will be engineers, without the right
expertise, time and tools.
I'm wholeheartedly opposed to incorporating any of these value-judgment assertions in the standard.
There is only one value judgment in the paragraph you speak about: "not
recommended" [allowing the transfer of raw encrypted data]. This is the
same issue as above: do you consider data inspection, traffic analysis a
threat? If not, we have to discuss it. If yeas, you should warn the user
about the vulnerability the raw data access opens up.
In any case, if there will be no mention in the standard (or in an
accompanying document) about the dangers, pitfalls, weaknesses, too, I
will have to vote against it. (I don't want my name or our company's
name associated with a standard, which leads to insecure
implementations, even if they are based on the standard used in the
wrong way.) I don't mind replacing "not recommended" with something
else, saying that a certain implementation would make the system
susceptible to traffic analysis type attacks, when the data can be
repeatedly inspected by an intruder. Since this was going into the
backgrounds chapter, I just felt a shorter warning suffices.
Zero-divisors will typically kill you here.
The tweak value T = K2*I. You only need that the probability of a
repeated T value is negligibly small. (Here you don't even need a ring,
a semigroup is sufficient.) If K2 is invertible, all T values will be
different. A trivial example was an odd K2 in the ring of residues mod
2^128, which might not be secure, but many others, like the elliptic
curve groups look just fine.
Laszlo
-------- Original Message --------
Subject: Re: "the most important applications"
Date: Tue, January 17, 2006 4:07 pm
...
We came back to my point that in the most important applications,
disk-internal encryptions, there is NO interoperability.
Laszlo, it is legitimate for you to have this viewpoint, but we have to
be very careful that the standard does not contain any wordings that
suggest that "the most important applications" are this technology or
the other.
Accrdingly, I very much object to the following comments (taken from a
previous post from Jan-15):
1.1 (first line) to be added: in magnetic (hard) disk drives.
Not necessarily, other technologies can use it as well.
... and external encryption is not best served with this standard.
That's your opinion, others may disagree. There should be nothing in
the standard to support (or refute) this opinion. We are not in the
business of evaluating which technology is best suited for "secure
storage".
--- (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?
I'm wholeheartedly opposed to incorporating any of these value-judgment
assertions in the standard.
And, why do we use this finite field, at all? There are simple rings,
which should work here better.
Not that I know of. Zero-divisors will typically kill you here.
-- Shai
