NIST publishes new DSA draft

David Shaw wrote:
>>We might want to think about making SHA-256 be
another MUST algorithm.
>>The only MUST hash now is SHA-1.  Making SHA-256 be
a MUST would make
>>these new key sizes be more useful, and also give us
an easier fallback
>>if SHA-1 should be broken.
> 
> 
> Unless DSA2 is also a MUST, I wonder what the practical
advantage to
> that would be (beyond making the social point that we
really, really
> want people to move away from SHA-1).


I think this is pretty much all of the point.  Any
new DSA signing method or other usage will likely
be non-obligatory, but pushing the implementations
into that direction seems useful.

> right answer.  Now that we have actual information
about DSA2, perhaps
> it would be worth revisiting that question.  A new
algorithm ID for
> DSA2 resolves a number of problems in one fell swoop as
there is no
> expectation of interoperability.  SHA-256 is always
usable
> (effectively the default) for DSA2, and there is no
problem with
> knowing when it is possible to use truncation (always).

Sounds good to me.

iang

On Fri, 17 Mar 2006 16:01:25 +0100, Ian G said:

>> right answer.  Now that we have actual information
about DSA2, perhaps
>> it would be worth revisiting that question.  A new
algorithm ID for
>> DSA2 resolves a number of problems in one fell
swoop as there is no
>> expectation of interoperability.  SHA-256 is always
usable
>> (effectively the default) for DSA2, and there is no
problem with
>> knowing when it is possible to use truncation
(always).

> Sounds good to me.

I support this too.  The majority of keys are DSA keys q=160
bit.
Having a new algorithm indentifier will help more than harm.



Salam-Shalom,

   Werner

On Fri, Mar 17, 2006 at 04:54:21PM +0100, Werner Koch wrote:
> 
> On Fri, 17 Mar 2006 16:01:25 +0100, Ian G said:
> 
> >> right answer.  Now that we have actual
information about DSA2, perhaps
> >> it would be worth revisiting that question.  A
new algorithm ID for
> >> DSA2 resolves a number of problems in one fell
swoop as there is no
> >> expectation of interoperability.  SHA-256 is
always usable
> >> (effectively the default) for DSA2, and there
is no problem with
> >> knowing when it is possible to use truncation
(always).
> 
> > Sounds good to me.
> 
> I support this too.  The majority of keys are DSA keys
q=160 bit.
> Having a new algorithm indentifier will help more than
harm.

Even though I originally brought it up, I've given this a
good bit of
additional thought while mailing with Hal on the list
yesterday, and I
think it really does come down to something as simple as a
question of
error messages.  I'm not for a new algorithm ID.

It breaks down like this:

1) a q==160 signature without truncation (hash size matches
q exactly)
2) a q==160 signature with truncation (hash left-truncated
to match q)
3) a q!=160 signature without truncation (hash size matches
q exactly)
4) a q!=160 signature with truncation (hash left-truncated
to match q)

I'm not mentioning the larger key size in DSA2 as I believe
that
deployed code will handle larger DSA key sizes correctly.

Obviously #1 isn't a problem, as it is what DSA is today. 
I think PGP
can actually do #2, but for the sake of argument, let's say
that
nobody can do #2, #3, or #4 on current code.

If we don't assign a new algo ID for DSA2, #3 and #4 will
fail because
of the wrong q size, and #2 will fail because of the
truncation.  If
we do assign the new ID, as before #2, #3, and #4 will fail
- but so
will #1!  Even though the signatures are compatible, the new
algo ID
will cause the signature to fail on the older
implementation.  This
argues against a new algo ID.  Even if we don't create DSA2
q=160 keys
(internally changing them to DSA1 keys), this just returns
the
question to neutral, and the extra code complexity and
questions (will
it break any keyservers? It will certainly break pksd) of
assigning
the new algo ID argue against it.

David

I think we ought to keep it with the same algorithm number.

I'm happy to put in SHA-224 (meaning it's trivial work),
but I don't  
like it, myself. The reason is that SHA-224 is really a
truncated  
SHA-256. Thus, it has no advantages over SHA-256 except
being smaller  
by 32-bits with 112 bits of security. The reason it exists
at all is  
for crypto-balance with 2-key 3DES (which is not TDEA),
which we  
don't allow at all. I don't think we should have it as it
goes  
against our principles of wanting a minimum of 128-bits of
security  
in OpenPGP. (Yes, yes, I know that SHA-1 doesn't meet this
either,  
but until SHA-256, we didn't have many options. That
doesn't mean the  
principle is wrong; we *have* options.)

	Jon

Jon Callas wrote:
> 
> I think we ought to keep it with the same algorithm
number.
> 
> I'm happy to put in SHA-224 (meaning it's trivial
work), but I don't  
> like it, myself. The reason is that SHA-224 is really a
truncated  
> SHA-256. Thus, it has no advantages over SHA-256 except
being smaller  
> by 32-bits with 112 bits of security. The reason it
exists at all is  
> for crypto-balance with 2-key 3DES (which is not TDEA),
which we  don't 
> allow at all. I don't think we should have it as it
goes  against our 
> principles of wanting a minimum of 128-bits of security
 in OpenPGP. 
> (Yes, yes, I know that SHA-1 doesn't meet this either,
 but until 
> SHA-256, we didn't have many options. That doesn't
mean the  principle 
> is wrong; we *have* options.)

In general I'd agree that the less algorithms/lengths
the better.  I'd certainly be keen to drop SHA-224 if
there is no good reason for it.

iang

On Sun, Mar 19, 2006 at 11:51:17AM -0800, Jon Callas wrote:

> I'm happy to put in SHA-224 (meaning it's trivial
work), but I don't  
> like it, myself. The reason is that SHA-224 is really a
truncated  
> SHA-256. Thus, it has no advantages over SHA-256 except
being smaller  
> by 32-bits with 112 bits of security. The reason it
exists at all is  
> for crypto-balance with 2-key 3DES (which is not TDEA),
which we  
> don't allow at all. I don't think we should have it
as it goes  
> against our principles of wanting a minimum of 128-bits
of security  
> in OpenPGP. (Yes, yes, I know that SHA-1 doesn't meet
this either,  
> but until SHA-256, we didn't have many options. That
doesn't mean the  
> principle is wrong; we *have* options.)

I understand the argument about wanting 128 bits of
security, but
since the new DSA allows a 224 bit q, there just isn't room
for 128
bits of security.  Whether we truncate SHA-256 and call it
"truncated
SHA-256" or truncate SHA-256 and call it
"SHA-224", we have to
truncate.

We support DSA now, with a note saying that if someone wants
DSS, they
need to use SHA-1.  I suspect we'll end up in a similar
place with
DSA2 allowing whatever key size and q size that people want
to use and
a note that if they want DSS they need to use one of the
four
NIST-blessed key size / q size pairs.

I lean towards adding SHA-224 as one of those four pairs has
a 224-bit
q, and NIST suggests SHA-224 for this size.  It's only a
lean towards
adding it as NIST also suggests truncated 256, 384, or 512
as valid
options, so 224 is not the only game in town.  (384 seems a
little
silly as it would be a truncation of a truncation, but it's
an
option.)  It's really a feeling that we currently support 4
out of the
5 FIPS-approved hash functions (SHA-1, 256, 384, 512), and
since
supporting the 5th (224) is so trivial, we may as well be
complete.

I'll defer to someone who feels more strongly about this
than I do.

David

Just a quibble. Truncating sha-256 down to 224 bits does not
give the
same output as sha-224, as sha-256 and sha-224 use different
initialization vectors. So "truncated sha-256"
and "sha-224" really
would be totally different hash values.

No comment on the rest of what you say.

	Tony Hansen
	tonyatt.com

David Shaw wrote:
> I understand the argument about wanting 128 bits of
security, but
> since the new DSA allows a 224 bit q, there just isn't
room for 128
> bits of security.  Whether we truncate SHA-256 and call
it "truncated
> SHA-256" or truncate SHA-256 and call it
"SHA-224", we have to
> truncate.

No, it is not the same output, but it is the same amount of
security.
Which hash and which IV doesn't matter here - just that the
end result
is 224 bits long.

David

On Mon, Mar 20, 2006 at 04:08:28PM -0500, Tony Hansen wrote:
> 
> Just a quibble. Truncating sha-256 down to 224 bits
does not give the
> same output as sha-224, as sha-256 and sha-224 use
different
> initialization vectors. So "truncated
sha-256" and "sha-224" really
> would be totally different hash values.
> 
> No comment on the rest of what you say.
> 
> 	Tony Hansen
> 	tonyatt.com
> 
> David Shaw wrote:
> > I understand the argument about wanting 128 bits
of security, but
> > since the new DSA allows a 224 bit q, there just
isn't room for 128
> > bits of security.  Whether we truncate SHA-256 and
call it "truncated
> > SHA-256" or truncate SHA-256 and call it
"SHA-224", we have to
> > truncate.

Jon Callas wrote:
> 
> I think we ought to keep it with the same algorithm
number.
> 
> I'm happy to put in SHA-224 (meaning it's trivial
work), but I don't
> like it, myself. The reason is that SHA-224 is really a
truncated
> SHA-256. Thus, it has no advantages over SHA-256 except
being smaller by
> 32-bits with 112 bits of security. The reason it exists
at all is for
> crypto-balance with 2-key 3DES (which is not TDEA),
which we don't allow
> at all.

<pedantic>

3-key DES also has a strength of 112 bits.

</pedantic>

> I don't think we should have it as it goes against our
> principles of wanting a minimum of 128-bits of security
in OpenPGP.
> (Yes, yes, I know that SHA-1 doesn't meet this either,
but until
> SHA-256, we didn't have many options. That doesn't
mean the principle is
> wrong; we *have* options.)
> 
>     Jon
> 
> 


-- 
http://www.apache-
ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he
can go if he
doesn't mind who gets the credit." - Robert Woodruff

On 26 Mar 2006, at 3:12 AM, Ben Laurie wrote:

> Jon Callas wrote:
>>
>> I think we ought to keep it with the same algorithm
number.
>>
>> I'm happy to put in SHA-224 (meaning it's trivial
work), but I don't
>> like it, myself. The reason is that SHA-224 is
really a truncated
>> SHA-256. Thus, it has no advantages over SHA-256
except being  
>> smaller by
>> 32-bits with 112 bits of security. The reason it
exists at all is for
>> crypto-balance with 2-key 3DES (which is not TDEA),
which we don't  
>> allow
>> at all.
>
> <pedantic>
>
> 3-key DES also has a strength of 112 bits.
>
> </pedantic>
>

There are certainly good arguments for that, but if 3-key
3DES is no  
stronger than 2-key, then there shouldn't be any harm in
dropping the  
third key. Right? If you don't like this idea (that 2-key
and 3-key  
are equivalent), which I don't, then 3-key must be some
stronger. It  
just isn't easy to know how much more.

I wrote a long thing on this a couple years ago at:

<http://sear
chsecurity.techtarget.com/tip/ 
1,289483,sid14_gci968714,00.html?track=NL-102&ad=486202&
gt;

	Jon