dontspam-tzeruch(_at_)ceddec(_dot_)com says:
Well we have common IDs, but no specs for what a lot of the IDs point to.
No Detail. So there are lots of different and non interoperable ways
of implementing what already is there. And that is my point.
Hmm... Why didn't you say so. With this point I can't argue.
Except lots of these already exist in this state in the existing spec.So
the current spec is stupid? It isn't *reserving* numbers for algorithms,
it is *defining* them. And without specifying all the details.
Without answering the question, I'd say that a list of discrepancies
would make fixing those less-than-perfect specs easier. I certainly
wouldn't like just throwing the "unclean" pieces out. Making them
"clean" would be the best.
You want to add incomplete definitions of new algorithms to the
existing incomplete definitions and submit the spec in this incomplete
state?
Hmm... A good question (at last :-).
Had I any time before September (I'm working on two publications and
am behind the schedule as is) I'd have said "Yes and I'll make 'em
complete." As it goes, I won't be able to invest any efforts worth
mentioning until September. By then it probably will be solved
one way or another...
The spec ..............does say (5.7):
The body of this packet consists of:
- Encrypted data, the output of the selected symmetric-key cipher
operating in PGP's variant of Cipher Feedback (CFB) mode.
and so on, implying that ALL algorithms must use the CFB mode.
So what do we do with stream ciphers? Leave them alone until the
next version? [I could live with that decision.]
...PGP-CFB and advertised the fact and no one said anything about me getting
it wrong, so I assume I got it right - and I asked about DES/SK at that
time. ID 6 means DES/SK in PGP-CFB mode. That is what the spec says.
Damn. I dislike this PGP-CFB mode, but I can live with it.
If you want it in "raw" CFB it would need another ID.
Nein. I don't want it in "raw" CFB bad enough to justify a whole
new ID. My sanity check won't permit it. (:-)
The spec should say a lot of things. I can only go by what it actually
does say. And it says I "MAY" implement this algorithm - DES/SK-PGP/CFB.
And I plan to if it remains in the spec as soon as I obtain source for the
algorithm. This detail has been around for months.Did anyone else notice it?
How would anyone else have implemented DES/SK - raw, raw-cfb, or PGP-CFB?
So let's make the spec to state explicitly:
UNless Otherwise Specified, all the block ciphers are to be
implemented in PGP-CFB-<Blocksize> mode.
.............You can blame the people who came up
with the broken standard, but I don't see anyone who has stopped using the
broken implementations, and worse, new implementations must copy the bad
features. History shows that correct implementation don't superceed
broken ones - they adopt the flaws in order to interoperate.
A good point. However you're talking about major features of major
very popular products - where being incompatible with an earlier
released bug is instantly and unpleasantly noticeable...
If those advocating the algorithms won't take the time to insure they are
specified completely and correctly, who is going to take time to do the
harder job of implementing them correctly? Especially when the correct
implementation may not be the one in the spec.
A fair point. But speaking for myself, I won't be able to contribute
until September.
So there are three alternatives:
1. Delete the unimplementable algorithms (reserving the numbers) and hope
that someone wants to define them in the next revision, but submitting
a clean spec.
Not nice...
2. Don't submit the spec until these things are defined (and I don't
see anyone rushing to do the necessary legwork so this might take a
very long time).
The most "right" but probably unacceptable because of time...
3. Submit a spec with ambiguities that will create lots of opportunites
for interoperability problems.
My original post was a fourth suggestion:
4. Leave the ambiguities in but identify them and tell implementors not to
use them widely because they are ambiguous and won't interoperate
because the details are unclear.
I am open to a number 5 if anyone has one. I am against number 3. Many
have expressed that we need to get something out now, so #2 is probably
not acceptable.
To identify and list the ambiguities is good. I suspect that when you do
that, it turns into a correction/solution list...
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>