Laszlo, I do not want to start a flame war, it is too tiresome. I fully agree with Shai, but would like to add several observations of my own.
Many of your messages were not answered not because of agreement, but because of the desire to prevent useless discussions. For example, discussions of whether the standard applies to flash-based drives in addition to magnetic media are not productive. You seem to want to include too much into the standard. Some of what you are trying to include is colored by your focus on your company products. This is understandable, but there are other companies around, with different products and different security targets. Some is colored by your desire to be able to say that "if you are compliant, you are secure", which I think is not achievable in a single standard. As I have written several times before, the compliance with the standard DOES NOT guarantee security of the system. It is only a building block, nothing more, nothing less. Explaining all of the security implications is far beyond anything we can include in the standard. Roughly speaking, the goal of the standard is to propose a mode of encryption that does not expand data and gives some protection against copy and paste operations from one sector to another. Additional goal is to specify the parameters that are necessary so that one implementation will be able to decrypt what was encrypted with another implementation. Essentially, this is all we can hope to cover. There are a million attacks that the LRW-AES does not protect against. There a million ways to make the system compliant with the standard and at the same time being completely not secure. Explaining these issues is outside the scope. All we can do is encourage implementers to use common sense and to try and comply with FIPS/CC. Hope this message will stop the avalanche of mail messages. -serge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 17, 2006 3:02 PM To: Shai Halevi Cc: SISWG Subject: RE: "the most important applications" >>[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
