Landon:
Thank you for your contributions. One of these suggestions I support
and the other I think you still have more homework on.
On Jan 18, 2006, at 1:26 PM, Landon Noll wrote:
Please be so kind as to add this to rationale:
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 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.
I think this is a well reasoned sentence and I believe it should be
worked into the document. Thanks.
As well as:
There are a numerious attacks that the LRW-AES does not protect
against. There numerious to make a system compliant with the
standard in a completely insecure way. Explaining these issues
is outside the scope of this standard. The intent of this
standard is to encourage implementers to use common sense and
to try and comply with FIPS/CC.
I will tell you my problem with this paragraph (as an individual
contributor) and then give you some suggestions more productive ways
of bringing this issue back to the committee (as the chair). The
negative may sound harsh, but it is not, and I hope you do not take
it that way.
The problems with the paragraph include: The words "numerous attacks"
is subjective and vague. The second sentence is not a sentence. After
reading the last sentence, I have not seen the value it has given to
the reader beyond the obvious. To highlight this I will dissect the
final sentence. This is a compound statement, each of which are:
The intent of this standard is to encourage implementers to use
common sense
and
The intent of this standard is to encourage implementers to try and
comply with FIPS/CC.
Neither of these statements are "the intent" of this standard. I may
be quibbling about words, but this is what we are here for because at
the end of the day, all that is left on the paper will be these
words. We need to be critical of these words.
To make a productive contribution to move this idea forward, I would
ask you to do one or more of the following three options.
1) Find a similar statement in other standards. CBC, Counter, OCB,
etc. all have issues that some can call "numerous attacks". Use the
stuff on the NIST site as a preferred source. Find how others have
taken care of this in their text. If you find a vague statement like
I you have suggested in a sanctioned standards document I will
provide a formal apology. Concrete examples will be a far more
productive.
2) Once we are done, NIST will be looking at making this also an US
standard. NIST's criteria is based on two issues. Adoption by
relevant vendors, and the lack of credible criticism. If you write
such a paper, I would suggest (in addition to sharing it with this
group if you like) that you submit this to known cryptography
conference. If it is accepted, then you have a significant
contribution to the community.
3) If you believe you are being stonewalled by the editor, make a
formal motion and force a vote and live by the result. This is the
most risky without doing items 1 or 2 beforehand.
Thank you for your contributions.
Jim
