On Mon, 29 Jun 1998, Uri Blumenthal wrote:
dontspam-tzeruch(_at_)ceddec(_dot_)com says:
If there is an algorithm number assigned, it would be useful if there was
a specific reason to use it and a likelyhood it would appear in many
implementations. In this, I agree with PRZ that having extra algorithms
simply for the sake of having extra algorithms is not a good idea.
Algorithm numbers are assigned so that IF two people decide to use
THAT particular algorithm, they have a common ID for it and a spec
they can follow to interoperate.
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.
Sane ones would reserve the next number for AES and put together a mode
in which AES should be used, because it would be even more stupid than
keep this argument going, to think that it is enough to just define a
cipher without specifying all the details, like mode, IV, prefix, key
thingie and such.
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.
Don't you understand that an "implementable" algorithm specification must
include such minute details as what mode it is to be used in, what kind
of key, what kind of IV if any etc...? It is not enough to just have
an implementable crypto-engine.
...
Those who write the spec will have to decide whether they want "normal"
CFB, PGP-CFB or both. In the unlikely case they want both - you will
have to have TWO identifiers: one for the "normal" and one for the
PGP-CFB. Naturally, a spe that doesn't tell that is incomplete.
I thought the spec (for this revision) was in final call and isn't being
written any further and editing is limited to only the most severe
problems. You want to add incomplete definitions of new algorithms to the
existing incomplete definitions and submit the spec in this incomplete
state?
The implementor, s****d. In your implementation - you do. So you
must implement the MUST ones, you should implement the SHOULD
ones, and the rest is entirely up to you. What is there NOT
to undertand?!
Now DO YOU get it??
So if you implement DES/SK as raw, using algorithm ID 6, it is my option
to implement a PGP-CFB DES/SK also using algorithm ID 6.
No... Sigh... The spec should say that DES/SK ID 6 uses "raw" CFB. If
you want it with PGP-CFB, it would be ID 7, 17 or whatever.
The spec does not say this. But it 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. Nowhere
does it mention the use of any Cipher in "RAW" or raw-cfb mode and any
such exception should have been clearly stated. I implemented SAFER in
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. If you
want it in "raw" CFB it would need another ID. 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?
For a new algorithm I might have the first working
implementation, and then *my* implmementation will be copied - modes and
other details and all (because I can verify messages and produce a test
suite). So I might even kill an algorithm by doing a bad implementation
that gets widely adopted but rarely used.
Unless somebody finds enough time and desire to to the implementation
right - and then it would your implementation and its implementor that
"reap the blame"...
Which is why PKCS12 has all problems since Microsoft didn't get it right
(neither did Netscape) and now everyone has to copy them? I don't see
them moving to the correct implementations. X509 has lots of small
problems that no one is correcting. 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. I already
gave the example of SSL/TLS. All SSL implementations need to compensate
for bugs if they want to interoperate widely.
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.
I stand neutral on algorithms - I have done the work to make those I could
implementable so I know which ones are and what the problems are. But I
wouldn't mind deleting many, and would prefer removing all that would
cause interoperability problems.
If you were asking quesitions like: "Algorithm X is not implementable
cleanly because the spec doesn't tell A, B, C and D is unclear - how
do we define those missing links?", I'd applauded you. When you start
castrating the program, I become annoyed.
I have been pointing these problems out for months. Well it is now final
call, so there is no time for me to repeat my questions about what is
missing (or do I hear a suggestion that we don't submit the draft for
another two months). No one defined these things, nor have I seen any
messages filling any gaps in the specifications.
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.
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).
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.
--- reply to tzeruch - at - ceddec - dot - com ---