> > There are other alternatives, too, which
> > are much better in this regard. I do not insist on reviving EME,
>
> I am excited that a 4k "EME like" algorithm (I seem to recall that
> there were 2 proposed in addition to EME that were either royalty
> free or claim to donate the IP to the standard). I very much
> recommend that you work with on this idea and bring a proposal. The
> requirements are that the mode be written up, a sketch of a proof
> (that needs to be completed and published at a tier 1 conference),
> test vectors and IP statement citing prior art. Sample code is a
> definite plus.
>
> I would like to hear a consensus from the other members that a new
> PAR P1619a for large block encryption would be warranted? My vote is
> yes.
I believe that a large block encryption is warranted.
> > why should we spend our time on
> > standardizing something we would never use?
>
> By "we" you mean Seagate/Maxtor? There are others in this community
> that are implementing LRW that believe that the traffic analysis
> vulnerability of LRW is OK.
>
> We (the cumulative P1619 based on several group votes) are working on
> LRW -because- it is the lightest weight thing that we could do. If
> you believe there is a mode that is lower weight then (I don't think
> I am being presumptuous in suggesting that) we are all ears.
I share the some of his concerns about LRW.
=-=
Let me offer this observation: I get the sense from the working group that when some people, particularly new people, raise various objections to the LRW proposal, there is a collective grown from some of the long standing members. Some rather helpful members of the group attempt to explain that the working group has gone over this ground many times before and a consensus has already been reached.
Frustrating as it may seem to go over the same ground again and again, I believe these "here we go again" moments are an important sign for the working group. The group should seek to understand the nature of the object or concern and then >>document<< the response (perhaps in the form of rationale) in suitable form in the next draft.
The reason why some new members revisit "old ground" could be that the draft fails to document both consensus and decision rationale. Unless this "old ground" is address in a form other than "we already discussed that", I suspect the draft might be headed for trouble at both the IEEE balloting level and perhaps in adoption (as we have been told before) as well.
I believe if the document attempted to address some of these "old ground" subject areas; it might gain a wider consensus, smooth out balloting, and perhaps speed adoption by vendors. Many years ago when I was working in p1003, we found this parallel rationale text valuable in this regard. When a new attendee or a balloter raised an old objection or concern, we would point to specific existing rationale text and ask them to consider it. Often it would. Where it did not, we asked if additional rationale might be added help document the group consensus.
Here is a specific suggestion: We ask people on the mailing list to re-raise any objections or concerns that they may still have with the current LRW draft. Then those who believe they hold the majority/consensus point of view should draft a response. Perhaps this response might be in the form of a FAQ style rationale such as:
Q 1.3: "Why does blah blah blah?"
A 1.3: The working group considered "blah blah blah" and came to the consensus that "foo bar baz" was a better approach. They felt that for because of "curds and whey", the XYYZY had to be PLUGH. ...
Float that by person(s) who raised the original objection or concern. Edit as needed and add it to the document. You may not get total agreement, but at least you will document the common issue as well as document the consensus in response.
chongo (Landon Curt Noll) /\oo/\
