dontspam-tzeruch(_at_)ceddec(_dot_)com says:
.........
I would rather delete every assigned algorithm number that isn't likely to
be implemented for public consumption than to have those show up, one per
implementation so no two implementations can talk except with RSA/IDEA/MD5
or DH/DSA/SHA1/3DES since my code will be much smaller if I just
implement these two subsets exactly.
You have already said that several times. Enough is enough.
I'm explaining for the last time. RFCs define "how" things must be
implemented, if at all.
MUST are the algorithms that you must have, otherwise you are not in
compliance with that RFC.
SHOULD are the algorithms that you can claim compliance even not having
those implemented, but you must have a really good (and convincing for
your customers) reason and explanation why you didn't include them.
MAY are the algorithms that is entirely up to you to have or not to
have. So the keys that are "for real" aren't likely to be of one of
them... MAY class says: "If you decide to do this - here is how it
must be done." So that *if* two implementations both have a common
subset of the MAY class, they could interoperate using them, too.
And then there will be no reason to
have any other algorithm, so why bother putting them into the OpenPGP
spec? If we have them as official, they should be limited in scope so
that it is possible to produce a full implementation.
The reason is that some people want more than the MUST gives them, and
IETF does not want to forbid that.
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.
I really wish you'd learned something about IETF before making loud noises.
"Can't use" is necessary in the absence of strong
language saying "Don't Use".
Neither one is necessary. IETF managed to live without it till now
and hopefully will keep surviving even your onslaught.
If you admit that different vehicles might be designed for different local
conditions, why is it hard to believe that different algorithms or
implementation levels might be designed for different usages?
That isprecisely why mAY algorithms are NOT required to be there. The
only thing MAY mandates, is that IF you have one or more of those,
then THIS is the way to implement them.
I don't want to see keys with preferred algorithms of 100 on keyservers,
nor do I want to see any with MAY algorithms on the preferred list of any
key submitted to a server.
And I don't want to see any of your keys on a server regardless, nor to see
your e-mails cluttering the list. I guess we both don't get our wishes.
So should we delete DES/SK and reassign it as "whatever AES is", or
reserve the next number as "whatever AES is"?
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.
There is already a category for undefined algorithms.
We aren't talking about "undefined" here and now.
So if you define a number for
X now, and AES is X+ do we assign a new, different number? What if there
are already messages using X if we want to keep the number?
AES won't "fill its position" until tested. At that time whatever that X
is, will have the number of X. If later on (a month, a year, a decade)
an X+ comes out - how different is it from a (hypotetical) discovery
that IDEA needs strengthening against "quadruple" attack and from
now on everybody should move to IDEA+?
[This was a rhetoric question - no need to bother answering.]
Is SKIPJACK not qualified to be an "example" of a new encryption algorithm
that one MAY implement?
That is what the experimental numbers 100-110 are for.
If you design a cipher, it will be "experimental". I daresay SKIPJACK is
more than that.
Do you interoperate with raw algorithms, or with cfb-reset-after-10?
Isn't it bloody obvious that an algorithm definition must be specific
enough to be unambiguously implementable (and make sense at the same
time, so ECB mode isn't likely to cut it, for example)?
Do you really have this much free time on your hands to ask such questions?
Well, IDEA, 3DES, CAST, Blowfish, and SAFER/SK-128 are all specified
clearly in other documents and PGP doesn't implement them directly, but
puts them through the PGP-CFB code (and does not say that these must do
this) and the specification says nothing about any new algorithm. This is
an ambiguity in the spec.
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.
You keep proposing adding algorithms by some title. I have code that can
implement it either raw, or via the PGP-cfb reset or even by other means.
I can do that now (and have done it with RC2 and RC4). And there are
other modes. Which do I do? I have two switch statements, one for
PGP-CFB and one for raw. For consistency, I should go through PGP-CFB.
But to be absolutely true to a spec I should go with raw.
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.
If you implemented RC2 only with PGP-CFB (ID223) and I implemented RC2
only with "normal" CFB (ID224) then our implementations won't be able
to interoperate using RC2. Simple. MAY guarantees interoperability ONLY
if both entities did implement the algorithm in question.
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.
Lest you think this irrelevant, Blowfish ALREADY RAN INTO THIS PROBLEM.
I implemented it as 128bit/16 rounds in CFB mode, but another implementor
was first and used a 192 bit key as I remember. Mine won and the only
reason was because I clarified the specification first and not for any
technical reason.
Since you seem to have already learned the hard way that the specs must
be complete in order to be usable, what is all this **** about?!
I already have many more algorithms I can implement instantly since they
are already contained within SSLeay. I have avoided suggesting them
because I don't want the number of algorithms to grow.
That is your choice. You are entitled to it. My choice is different. I
hope that it is my choice that is in line with the WG's position.
There are EXPERIMENTAL algorithm IDs and there are MAY algorithm IDs. Not
all the MAY algorithms are specified in enough detail for anyone to
implement unambiguously (those that exist as code somewhere).
So that should be dealt with, and the ambiguity has to be removed.
Now do you feel enlightened.
Instead you are saying it is up to each individual implementor to use his
own judgement or that there should be some free-for-all to decide which
variant of each MAY algorithm will win.
Why don't you read what I say, instead of putting [foul] words in my
mouth (<spitting sound>)?
I said that it is up to each individual implementor to use his own
judgement on WHICH algorithms from the MAY group (if any) he will
put in HIS implementation. What the RFCs should say is exactly
HOW each of those MAY ones must be implemented, if at all.
There must be no "variants" except in your imagination. Each
differentone is, well, different and requires a diffeent ID.
No it is not. The natural selection will "wither" some of the defined
algorithms and make others "blossom". But it is absolutely not up to
you to guesstimate which ones will "live" and which ones will "die".
I don't have to guesstimate. All I have to do is implement first and get
the widest usage.
So do that. What's your problem?
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"...
How many of the corrections and clarifications in the specification have
you done? You seem to see it as a completed mathematical proof. I see it
as something with contradictions and assumptions (but far less than many
others), and not a single existing correct implementation.
In PGP-5 I've done zero corrections, as you bloody well know. I've done
plenty in SNMP, for example, and some other things.
A second algorithm protects against a point-failure. 3des and cast is
better than either alone.
You do not understand the idea of MAY algorithms. Fine, you don't have
to have those at all.
A list of 12 is much worse unless you measure code's value by the KLOC.
I measure it by the capabilities mapped onto my needs.
Cryptography is stronger when it is simpler.
More algorithms complicate everything.
I don't see how having 20 algorithms is any different wrt. to the
program logic than 3 or 4. And lest you asked, I've done quite a
fwe implementations of various things (yes, they work).
Why are you advocating that PGP become as bad, if not worse.
"Beauty is in the eye of the beholder". "Bad" for you" is "nice"
and "useful" for me.
Like having an available reference implementation of each algorithm you
are suggesting and maybe a sample PGP message using it?
Maybe.
I have done the implementation, and have run into the problems. I have
time to ask questions which you think silly now because it will take a lot
more time later to try to resolve why one "Open PGP" can't decrypt the
messages from another "Open PGP" when both don't do anything contradicted
by the spec.
That's why the specs have to be cleaned, and that's why there are
reference implementations before the standard advances. NOBODY IS
ARGUING WITH IT, BUT IT IS NOT THE POINT YOU ARE PUSHING.
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've spent enough of my time on this. No further message on this topic
will earn a response.
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>