>>[magnetic (hard) disk drives] Not necessarily, other technologies can use it >>as well. Jim repeatedly confirmed that P1619 is for spinning magnetic hard disks only. That is, not optical, solid state, magneto optical, electrostatic, organic, printed, tape, etc. It is important, because the assumption made were magnetic hard disk related: fixed size LBA's, consecutive numbered sectors, size preserving encryption, etc. If you have any other technology in mind, which shares all these assumptions, we can add that to the list.
>>[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" > From: Shai Halevi <[EMAIL PROTECTED]> > Date: Tue, January 17, 2006 4:07 pm > To: SISWG <[EMAIL PROTECTED]> > > [EMAIL PROTECTED] wrote: > > ... > > 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