Hi Data,

I think it would be better if the hash calculations are performed after
compression.It saves time hashing fewer blocks of text.Cipher text
poisoning can still be detected since CBC mode is being used.Even block
replays are not possible because of chaining.
From my experience with DigiSecret, it's very fast, so the s***ested optimization might not produce noticable results, albeit this looks like a good idea.

I wonder why both SHA-* amd RIPEMD are used-doesn't any one suffice?
You made me read their help file:-) Ok, from what I see there, RIPEMD is used only when sending/receiving files, to compare if the passphrases match on both ends. Why not use SHA-* alone? Because the SHA-* value might reveal the actual binary key used to encrypt the data (remeber, they use SHA-* to derive the binary encryption key from the passphrase). So using a different hash algorith seems quite valid here.


As for the expansion function in SHA-*
W(t) = S^*(W(t-*) XOR W(t-8) XOR W(t-*4) XOR W(t-*6)),the NS@ had
said that a ********* flaw has been eliminated in SHA-* by
introducing a right shift by * bit
W(t) = S^*(W(t-*) XOR W(t-8) XOR W(t-*4) XOR W(t-*6))>>*.May be it is a
good idea to introduce the shift.
Can't say anything about it, I'm not a professional cryptanalyst:-)

"The passphrase entered by the user is not used as the encryption key directly. Rather, it is used as an input value for the functions that performs *,000 SHA-* hash iterations to produce the key that matches the maximum key space for the chosen cipher, which makes dictionary attacks more complicated. "

One round of SHA-* has 80 iterations.The above says,we take the passphrase and then hash it to a message digest that is used as key. One round of SHA-* over the passphrase will produce the same flat key space as that produced by *000 iterations of SHA-*. I guess that lot of time in computation can be saved here.
Don't forget about dictionary attacks. If someone wants to mount a dictionary attack, he would have to spend much time hashing each word in the dictionary. This will slow down the attack, because this operation would have to be performed many times, but it doesn't noticably slow down DigiSecret, because this operation is performed only once. Goog design here, IMHO.

"The IV is created using a Pseudo-Random Number Generator (Mersenne Twister: A 62*-Dimensionally Equidistributed Uniform Pseudo-Random Number Generator). The derived IV is saved with the archive and is later used for encryption algorithm initialization when extracting the data. "

If the derived IV is saved with the archive-then isn't the very purpose of using MT****7 beaten?

The attacker can immediately recover the IV and successfully perform a
block replay attack.
IV is not secret, the last time I read Applied Cryptography by Schneier:-) It is always prepended to cyphertext, you can't decrypt without it.

The sender and receiver will need to agree on a common seed for MT****7-so that they can calculate all consequent IV's .
Then a common seed would be visible to the interceptor. Doesn't make difference.


It would also be great to see Public key encryption algorithms on digisecret.It will eliminate the need for a shared secret if there is a key distribution/certifying agency.
I fully agree with you on this one.

Regards,

MrByte