Re: Question and note

[Uri Blumenthal <uri@xxxxxxxxxxxxxx>]

dontspam-tzeruch@xxxxxxxxxx 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@xxxxxxxxxxxxxx
-=-=-=-=-=-=-
<Disclaimer>