> Unruh wrote:

>> Mike Amling allspam.com> writes:
>>

>>> Dmitry Chumack wrote:

>>>> Hi *
>>>>
>>>> I have a question. There is few doesns of __terabytes__ of data. I need
>>>> to split this data to blocks of fixed size. Than I need to calculate a
>>>> sha1 hash for each block and store it. The question is which minimal
>>>> size of block I have to choose to minimize the probability of existence
>>>> of two equal hashes? What probability of such a coincidence would be if
>>>> I'll use an md5, crc32 or sha2 algorithms instead of sha1? Or if I'll
>>>> use a combination of this algorithms (e.g. sha1 and crc32 or sha2 and
>>>> md5 and crc32)?

>>
>> Unless the block size is less than 16 bytes do not worry about
>> collisions. (If it is less than 16 bytes you will get collisions because
>> the two blocks ...

>Dmitry Chumack wrote:

>> Hi *
>>
>> I have a question. There is few doesns of __terabytes__ of data. I need
>> to split this data to blocks of fixed size. Than I need to calculate a
>> sha1 hash for each block and store it. The question is which minimal
>> size of block I have to choose to minimize the probability of existence
>> of two equal hashes? What probability of such a coincidence would be if
>> I'll use an md5, crc32 or sha2 algorithms instead of sha1? Or if I'll
>> use a combination of this algorithms (e.g. sha1 and crc32 or sha2 and
>> md5 and crc32)?

> If you use SHA-1, you won't have any collisions. If you use MD5, you
>won't have any collisions unless the data has been specially constructed
>to produce a collision.

>--Mike Amling

> Mike Amling schrieb:
>

>>> http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf.
>>> As for pre-built implementations, try searching for crypto library c++,
>>> and look for DSS or DSA.
>>> Other digital signature protocols include ECDSA and RSA-PSS.

>> Note: I suggest RSA-PSS with exponent 3 when the application needs a
>> digital signature that can be verified quickly.
>>
>> --Mike Amling

>
> I'm using a DSA key to sign the data now (also including the keypair)
> and also base64 encodung the data after, so its not readable.
>
> Think this should be sufficient. And if someone is able to break the
> key ... he will also be able to remove the liciencing think kompletply
> from the app :)
>
> And best: Its all build in the DotNet framework 2.0 ...

>Are you so lame that you actually fear the government?

>Fuck politicians, police, and all others who attempt to control
>crypto.

>Cryptography protects our rights of privacy and those who cowtow to
>the pigs are not cryptographers at all. They are nothing more than
>crypto-narcs.

>Citizens of Iran, Iraq, North Korea, or anywhere can get a copy of PGP
>easily. Use BitTorrent, or simply visit one of the PGP international
>mirrors.

>Anybody who obeys export controls is a fool.

>Like V says: "People shouldn't fear their governments. Governments
>should fear their people".

> It wasn't personal. I overlooked your response.

>
> Salami Man wrote:

>> Take some of their advice with a grain of salt. I, by no means, am an
>> expert, but I /will/ tell you that using ROT-13 twice will provide you
>> the
>> same text as the one you started with. ROT-13 shifts the plaintext 13
>> letters forward in the alphabet:

>
> ... it's a joke.
>
> Typically given when people are asking for security primitives for
> situations where there is no security (or the security is weak). As in,
> you could use AES with a constant key of "secretkey", or you could use
> ROT-13, no wait, double ROT-13 for more security!
>
> Tom

> Ernest Hammingweight wrote:

>> Mike Amling wrote:

>>> If there are several titles on the disk, and they have different
>>> title keys (I don't know if that ever actually happens or not.), then
>>> CSS only needs one 409-element list per disk, rather than one
>>> 409-element list per title key. (Albeit one would think that
>>> space-saving would not be a major concern for DVDs.)
>>>
>>> --Mike Amling

>> That sounds plausible. Thanks.

>
> And it's also exactly what I said a few hours earlier. I guess because
> it came from me instead of Mike it was contained less truthiness? Well
> I'm glad we have a wikiality about this subject.
>
> Tom