Re: Re: DBMail 2.3.0 released

Aaron Stone wrote:
> I'm a big fan of double digest. I don't think the
algorithm matters much,
> just as long as the two are very different. Even just
MD5 and SHA1 should
> be plenty good, IMHO.
>   
No, not more than some checksum that was as long as the sum
of the two
checksums you were using.

If you want to be *certain* that you will only have one
different mime 
part for a give key,
you need a two part key where the second part of the key is
the sequence 
number (i.e. the first mime part with this checksum value,
the second 
one). In practice, most of the second
parts of the key will have a value of 1, but theoretically,
with 
multi-megabyte
attachments, millions of them could map to the same checksum
value.

If you double the length of the key, you only cut the number
of the 
maximum theoretical
value of the second key by half. But if you use a sequence
number for 
part of the key, you assure
that you will NEVER wrongly think two mime parts are the
same just 
because the checksums match.
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

On Tue, Dec 18, 2007, Matija Grabnar <matija+dbmailserverflow.com> said:

> Aaron Stone wrote:
>> I'm a big fan of double digest. I don't think the
algorithm matters much,
>> just as long as the two are very different. Even
just MD5 and SHA1 should
>> be plenty good, IMHO.
>>   
> No, not more than some checksum that was as long as the
sum of the two
> checksums you were using.

I believe that you are incorrect. If someone can
algorithmically break one
algorithm, regardless of its length, it is broken. That
someone can
simultaneously break two algorithms that generate that
hashes in very
different ways is much more unlikely.

> If you want to be *certain* that you will only have one
different mime 
> part for a give key,
> you need a two part key where the second part of the
key is the sequence 
> number (i.e. the first mime part with this checksum
value, the second 
> one). In practice, most of the second
> parts of the key will have a value of 1, but
theoretically, with 
> multi-megabyte
> attachments, millions of them could map to the same
checksum value.

I'm hearing that when there's a digest collision, people
want to see the
bytes compared to be double damned certain of not giving
wrong bytes.

Aaron
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Matija Grabnar wrote:
> Aaron Stone wrote:
>> I'm a big fan of double digest. I don't think the
algorithm matters much,
>> just as long as the two are very different. Even
just MD5 and SHA1 should
>> be plenty good, IMHO.
>>   
> No, not more than some checksum that was as long as the
sum of the two
> checksums you were using.

I've decided to offer some relief for those concerned. I'm
adding
libmhash as a build requirement, but that will add a lot of
hashing
algorithms.

By default dbmail will use SHA1 hashing for generating
unique-ids per
mime part. But dbmail will support using any algo supported
my mhash,
and you'll be able to do single or double digests, and you
can select
the hash(es) you trust not to generate collisions. Of
course, after you
change the hash(es) the ids in the mimeparts and partlists
tables will
have to be recalculated and updated, so dbmail-util will
have to support
that. And it will be up to the DBA to make sure the ID
fields are wide
enough to hold the keys.





-- 
 
____________________________________________________________
____
  Paul Stevens                                      paul at
nfg.nl
  NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
  The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail