headers
Hasnain Mujtaba | 5 Aug 2004 19:53

Partial chunking question


Hi all,

I had a question on breaking data into partial chunks. If someone can
clarify this, I'd appreciate it:

Suppose the chunk size you are using is 8192 bytes and the final data
chunk is less than 8192, say it is 6480. My chunking implementation puts
these final 6480 bytes into one non-partial length chunk so that the
chunk sequence looks like this: 8192, 8192, ... , 8192, 6480.

GPG and PGP, however, break this final data into power of two lengths,
i.e 8192, 8192, ... , 8192, 4096, 2048, 336. 

My approach interoperates with both GPG and PGP. But I am curious as to
why GPG and PGP break the final data this way, rather than putting it
all in one final non-partial chunk. I hope I have not overlooked some
RFC requirements.

Regards,
Hasnain

----
The information contained in this electronic mail and any attached
document is the confidential and proprietary business information of
Forum Systems, Inc. It is intended solely for the addressed recipient
listed above. It may not be distributed in any manner without the
express written consent of Forum Systems, Inc.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Shaw | 5 Aug 2004 20:20

Re: Partial chunking question


On Thu, Aug 05, 2004 at 01:53:40PM -0400, Hasnain Mujtaba wrote:

> I had a question on breaking data into partial chunks. If someone can
> clarify this, I'd appreciate it:
> 
> Suppose the chunk size you are using is 8192 bytes and the final data
> chunk is less than 8192, say it is 6480. My chunking implementation puts
> these final 6480 bytes into one non-partial length chunk so that the
> chunk sequence looks like this: 8192, 8192, ... , 8192, 6480.
> 
> GPG and PGP, however, break this final data into power of two lengths,
> i.e 8192, 8192, ... , 8192, 4096, 2048, 336. 
> 
> My approach interoperates with both GPG and PGP. But I am curious as to
> why GPG and PGP break the final data this way, rather than putting it
> all in one final non-partial chunk. I hope I have not overlooked some
> RFC requirements.

It's not an RFC requirement.  When writing a stream, GnuPG picks the
largest possible power of 2 for the amount of data it is ready to
write at that point.  I suspect PGP does something similar for similar
reasons.

What you are doing is also perfectly legal.

David
Permalink | Reply | 0 comments |
headers
vedaal | 18 Aug 2004 15:54

re-consideration of TIGER


now that sha-0 has been broken,
and sha-1 is actively being looked at for a possible extension of the
attack,

and MD5, HAVAL, and RIPEMD are also being attacked
http://eprint.iacr.org/2004/199.pdf)

would it be reasonable to re-accept the non-sha based hashes, (e.g. TIGER)
as a potential backup hash for implementations/users that may wish to
begin doing so?

vedaal

Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427
Permalink | Reply | 7 comments |
headers
Lutz Donnerhacke | 18 Aug 2004 16:41
Picon
Favicon

Re: re-consideration of TIGER


* <vedaal <at> hush.com> wrote:
> would it be reasonable to re-accept the non-sha based hashes, (e.g. TIGER)
> as a potential backup hash for implementations/users that may wish to
> begin doing so?

Unless the attack is not substantiated, wild actionism should be avoided.
Currently the attack looks like exploiting insufficient highest bit handling
of the internal state variables. This is a matter if the protocol applies a
random(!) padding directly before hashing.
Permalink | Reply | 2 comments |
headers
matic | 18 Aug 2004 18:21

Re: re-consideration of TIGER


Greetings,
the recent breakthrough appears to apply to all
the MDx based hash algorithms.
while TIGER is not, i am told, it does not mean that
it is more secure, as it has not been subject to same
scrutiny as the MDx based hashes.
i believe that less is better, however, diversity
is a good thing, especially when the algorithms
are un-related.  After all, this is the reason
why there are numerous algorithms in a crypto suite.
i am no expert of course, but it would be a cautious
thing to trim down the algorithms of similar ones
for the sake to complexity, and augment them with
dissimilar ones for the sake of hedging one's bet.
given the above a case for re-instating TIGER in openpgp
could be made.
hth
best regards
Imad R. Faiad

> 
> From: <vedaal <at> hush.com>
> Date: 2004/08/18 Wed PM 04:54:42 EAT
> To: ietf-openpgp <at> imc.org
> Subject: re-consideration of TIGER
> 
> 
>now that sha-0 has been broken,
>and sha-1 is actively being looked at for a possible >extension of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jon Callas | 18 Aug 2004 18:36
Gravatar

Re: re-consideration of TIGER


On 18 Aug 2004, at 6:54 AM, <vedaal <at> hush.com> wrote:

> would it be reasonable to re-accept the non-sha based hashes, (e.g. 
> TIGER)
> as a potential backup hash for implementations/users that may wish to
> begin doing so?
>

Not really, no. There are already perfectly good backup algorithms.

The reason we removed Tiger is that it hasn't been examined or used at 
all. None of these things apply to Tiger, and it is therefore still not 
well examined nor used. Going from a hash function that has been 
examined to one that hasn't isn't presently warranted.

SHA-1 isn't broken yet. Even the ones that have been broken haven't 
been broken (yet) in ways that permit signature forging. What we know 
now is that the functions we've been saying for close to a decade 
shouldn't be used really shouldn't be used.

If you're worried about SHA-1, you should move to SHA-256. Don't be 
scared by the fact that it's called "SHA."

If you want to do something *really* practical and good, stop using 
your V3 keys. (That's the editorial you, not vedaal specifically.)

I'm sitting in the hash sessions at Crypto now, and SHA-1 isn't broken. 
Again, if you still want to do something, start using SHA-256.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Weimer | 18 Aug 2004 18:53
Picon

Re: re-consideration of TIGER


* Lutz Donnerhacke:

> Unless the attack is not substantiated, wild actionism should be avoided.

Agreed.

> Currently the attack looks like exploiting insufficient highest bit
> handling of the internal state variables. This is a matter if the
> protocol applies a random(!) padding directly before hashing.

Source?

Based on my extrapolation of the pseudo-paper, it also depends where
the padding is added, if some length information is protected by the
hash, and the overall purpose of the hash function.  While MD5 has
certainly been broken, this doesn't seem to lead to immediate attacks
on real protocols.

(The impact on V3 keys could be interesting, though.)
Permalink | Reply | 1 comment |
headers
Lutz Donnerhacke | 18 Aug 2004 21:20
Picon
Favicon

Re: re-consideration of TIGER


* Florian Weimer wrote:
> * Lutz Donnerhacke:
>> Currently the attack looks like exploiting insufficient highest bit
>> handling of the internal state variables. This is a matter if the
>> protocol applies a random(!) padding directly before hashing.
>
> Source?

Personal impression.

> (The impact on V3 keys could be interesting, though.)

Of course.
Permalink | Reply | 0 comments |
headers
Len Sassaman | 18 Aug 2004 22:49

Re: re-consideration of TIGER


On Wed, 18 Aug 2004 vedaal <at> hush.com wrote:

> now that sha-0 has been broken,

SHA-0 was (theoretically) broken in 1998. The recent work is simply an
improvement in the break.

> and sha-1 is actively being looked at for a possible extension of the
> attack,
>
> and MD5, HAVAL, and RIPEMD are also being attacked
> http://eprint.iacr.org/2004/199.pdf)

Actually, all three are broken. But MD5 was (theoretically) broken in
1996, and RIPEMD has been considered weak for years. (Note, RIPEMD is
based on MD4.  It is *not* the same as RIPEMD-160 (based on RIPEMD, but
with considerable input from Dobbertin, who broke MD4 and MD5, or
RIPEMD-128 (based on RIPEMD-160, intended as a "drop in" replacement for
RIPEMD or MD4/5.)

> would it be reasonable to re-accept the non-sha based hashes, (e.g. TIGER)
> as a potential backup hash for implementations/users that may wish to
> begin doing so?

SHA-256 and SHA-512 are not based on the MDx family, and have arguably
gotten more scrutiny than TIGER. Even if SHA-1 or RIPEMD-160 were
threatened, we already have alternatives.

The bigger problem I see is with the lack of a sound hash function
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ian Grigg | 19 Aug 2004 01:20

Re: re-consideration of TIGER


Len Sassaman wrote:
> On a different note, I'm also in favor of dropping backwards compatibility
> with v3 in the spec, as I've mentioned before. This would also allow us to
> easily drop MD5 from v4. I think any backwards compatibility is adequately
> handled in the client implementations, and does not belong as a part of
> the OpenPGP message format. (I.e., there are clients that offer S/MIME
> compatibility, yet there's no reason for that to be part of this spec,
> either. We already have RFC 1991.)

I'm in total agreement there.

With one caveat - the chair would have to ponder whether
"this late" in the spec there are major changes allowed.

Some mentioned that v3 may be compromised even more by
this recent message digest news, and if so, that would be
sufficient casus belli, IMHO, to seriously consider doing
such a major step.

iang

PS: I note the comment on DSA/DSS keys ... if the above
logic doesn't fly, I'd suspect there is no case to drop
those keys, but I'm listening :-)
Permalink | Reply | 0 comments |

Gmane