Re: 2nd try at Algorithms Section

----- Original Message -----
From: "Jim Schaad" <jimsch5@home.com>
> > > 1. Where the IV is for these algorithms and where it is for a future
> > stream
> > > cipher or a counter mode cipher is not relavant.  These
> > algorithms can
> > > define their own behavior.
> >
> > But because we define the location of the IV in a location
> > other than with
> > the cipher definition any attempt to do that will break the spec.
>
> When I define a new algorithm I need to define 3 things: The URI for the
> algorithm, the XML structure of parameters for the algorithm and the
> processing rules to convert an octet string to an octet string.  These are
> independent for all algorithms created.  If I create an XOR encryption
> function, it does not have an IV defined anyplace and none is needed.

Actually if you use a synchronous block cipher it is even more important
that you use an IV, otherwise it's a vigenere cipher (I thought I covered
this).

> If I
> create an RC5 encryption function, the parameters (block size, key size
and
> rounds) could be defined in a) the URI, b)the XML structure or c) the
start
> of the cipher text (in a number of different formats).  This is totally
> independent of how 3DES defines it's own processing rules.

You are confusing things. Because we specify the location of the IV outside
of the specification of the encryption algorithm, the IV will exist in that
location if it exists at all.

> I disagree that putting the IV at the start of the cipher text means that
a
> new IV would always be used.  I don't think this item is settlable.

I never said that if they are in seperate locations then the IV will always
be different, what I said was that if they are in the same location they
must all be the same, and if they are in different locations they can be
different. If they are the same all security is lost with a large number of
chaining modes, with them in seperate places no chaining mode is harmed. Any
argument for placing the IV in a common location is an argument for
compromised security.> > > > > 12.  Section 5.3.1: change text to "at least
eight octets
> > > > long, containing
> > > > > no zero octets and long enough.."
> > > >
> > > > I would strongly disagree with that change. The supplied
> > > > weakening of the
> > > > random pool would supply leverage that could potentially be
> > > > used to attack
> > > > the system. Examples of this kind of flaw show up prominently
> > > > in public
> > > > literature regarding Germany's Enigma machine because it
> > > > allow a single
> > > > value as output (nothing mapped to itself).
> > >
> > > This is exactly the text that is in PKCS#1.  The key is
> > identified by
> > > scaning forward looking for a zero byte, the rest of the
> > item is then the
> > > key.  The existance of the zero byte seperates the padding
> > from the key.
> > > (Remember there is no data length encoded in the structure
> > anyplace.)
> >
> > There is an implied data length available when it is used to
> > transfer keys.
> > We will always know that X bits are needed for the key, they
> > can be simply
> > taken from the end. This means that all the prior data is
> > unexamined so
> > placing extra requirements on it can only lead to potential attacks.
>
> If you want to change PKCS#1 processing rules -- take it up with RSA.

Why bother? We can define better processing rules where if someone uses
something compliant with theirs it will be compliant with ours. There's no
reason to take it up with them.

> > > This recomendation is simply to match current practice in
> > the CMS world.
> >
> > And Germany had a "current practice" of using Enigma, it
> > doesn't mean it's
> > good, it just means that someone doesn't know any better.
> > OAEP has provable
> > security under a very small set of constraints, PKCS 1 v1.5 has a
> > compromising attack against it. From a security standpoint there is no
> > reason to even bother having PKCS1 v1.5, recommending it's
> > use instead of
> > something provably stronger doesn't seem like a course of
> > action I would
> > care to undertake.
>
> If you think this is true, then I assume you have argued strongly againist
> any incusion of RSA#1 v1.5.  Given that the best attacks I know of have to
> do with either a) bad padding or b) intereactive environments, I don't
think
> that this is a bad recomendation.

No I haven't argued against the inclusion of PKCS1 v1.5, the reason for
having it is that it has a large amount of mindshare. I will personally
elect not to use it, but I support it's inclusion in the standard.


> That is a key derivation algorithm.  I asked for a KeyWrap algorithm (i.e.
> encrypt a symmetric key with a symmetric key).

You got a key derivation algorithm, using a key wrap algorithm when there is
no requirement to negotiate the same key among n>2 parties is not wise, the
key derived from this will be provably at least as good (assuming the same
generator is used for the wrapped key and the nonce). If you want to use ot
for a key wrap, it takes 3 variables, the shared secret, nonce, and bK
(blinded key)
Generate DH shared secret S
acquire nonce N
pbK = hash(S | N)
key = bK XOR pbK

This will allow for a selected key. Doing so is easy enough, the generation
is:
Generate DH shared secret S
acquire nonce N
pbK = hash(S | N)
bK = key XOR pbK

I would recommend instead the use of the stronger version wherever
applicable. If you don't like that one, I've got a stack of about 50 other
strong Key Derivation algorithms that are vastly superior to CMSs

[snip SHA conversation until we get more opinions, I simply don't care]
                            Joe

Received on Wednesday, 6 June 2001 14:28:04 UTC