Serge, In the reflector there seemed to be a consensus, that a Backgrounds chapter is needed. There is an infinite sequence of questions, like, why did you choose something the way it is, have you considered this, is that not better, etc. Matt Ball is volunteered to write it and coordinate with you.
The ciphertext steeling stuff is also long and needs at least one figure. It affects many parts of the text. You are right, that there is no way to "convey all of the details needed for securing a system in a single standard". Nevertheless, having seen the many questions coming up in the discussions, we need to provide some information about the following: - What is the threat model, the attack scenarios? - What does the standard intend to solve? - What it does not? (Network/communication security, access control, traffic analysis) - What are the typical uses of the standard? - In what situations should it be avoided or enhanced with additional measures? - Pitfalls - Good practices (key generation, archival, backup) - Some alternatives and their relative merits, disadvantages; the rationale behind the selection of AES-LRW - Performance considerations, parallel implementations, sequential SW implementation - Some HW implementation issues (latency, multiple encryption engines, pipelining, secure RAM) As I wrote, a sentence that the algorithm should be resilient against dictionary attacks makes more harm than good. It has to be either removed or explained in more details, because there are dozens of attack types, which could be classified as dictionary attacks, and most of them are irrelevant, others are not feasible. The explanations of what we mean get several lines long, and they won't fit into the introduction. Instead of all the details, we have to provide references, where the concepts are explained in greater details. Laszlo > -------- Original Message -------- > Subject: RE: Procedure for 1619 (disk) > From: "Serge Plotkin" <[EMAIL PROTECTED]> > Date: Mon, January 16, 2006 6:16 pm > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, "SISWG" <[EMAIL PROTECTED]> > > Laszlo, > > What chapter do you have in mind ? > > There were some disjoint statements in the mailing list, but I do not > remember anything about a whole chapter. > > Lets remember that the goal of the standard is to teach/describe HOW to > do certain things, not WHY. In this context, the goal is similar to a > patent application - concentrate on explaining what you are trying to > patent, not on why you are trying to do this. > > There is no way we can convey all of the details needed for securing a > system in a single standard. In particular, fully describing attack > scenarios and proposed defenses against them is way out of context - for > those that have been involved in CC certification, just recall the > number of pages needed to describe something like this... > > > -serge > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Monday, January 16, 2006 1:02 PM > To: SISWG > Subject: RE: Procedure for 1619 (disk) > > Since a whole chapter is still missing (my comments have not been > incorporated: Addendum to Introduction, Dec 12, 2005 5:35 pm, to go to > this new Backgrounds chapter), like the handling of odd sized sectors, > and there are significant requests for changes, I think we don't have a > version we could consider to discuss, let alone to vote on. We should > modify our timetable: > > - We need a draft version with all the changes in, and two weeks for > comments. > - Then we need a meeting to discuss conflicting change requests, new > additions. > - Then we need a revised draft, and two weeks for comments. > - Finally, we could submit the final write-up for voting. > > Laszlo > > -------- Original Message -------- > > Subject: Procedure for 1619 (disk) > > From: "Shai Halevi" <[EMAIL PROTECTED]> > > Date: Mon, January 16, 2006 6:40 am > > To: "SISWG" <[EMAIL PROTECTED]> > > > > The minutes from the Dec-12 meeting say: > > > > > By December 25th Serge will update the doc with Laszlo's comments as > > > > instructed today during the meeting. Comments to this document shall > be > > > posted before January 15th to the reflector. The group will discuss > the > > > comments and decide to either reject or accept the comment. No more > > > comments will be accepted after January 15th, and by January 25th > Serge > > > will prepare a final version of the doc to be voted by Jan. 30th the > > > > group over email (one vote per company, at least half of the active > > > members should vote). > > > > Now that the Jan-15 deadline is over, let's try to focus on the > concrete > > comments that were made, so that Serge can prepare the "final version" > > for a vote. > > > > The comments that were entered (as far as I can tell) are the > following: > > > > * Changes to the underlying algorithm: there were a few posts > suggesting > > switching from LRW to something else. Specifically, in a message from > > Dec-21 Matt Ball suggested some LRW-variant > > http://grouper.ieee.org/groups/1619/email/msg00558.html > > and Mart Somermaa in message from Jan-6 suggested yet some other > modes > > http://grouper.ieee.org/groups/1619/email/msg00610.html > > > > > > * Extending LRW with "ciphertext stealing", see pictorial description > in > > a message from Laszlo on Dec-13 > > http://grouper.ieee.org/groups/1619/email/msg00483.html > > > > > > * There were many requests for adding rationale. Matt Ball is helping > > Serge on that front. > > > > > > * There were a few posts about specific wordings in the document, > including > > http://grouper.ieee.org/groups/1619/email/msg00582.html > > http://grouper.ieee.org/groups/1619/email/msg00631.html > > http://grouper.ieee.org/groups/1619/email/msg00632.html > > and maybe also others that I missed (?) > > > > -- Shai
