About DigiSecret

hi,

I was looking through the digisecret help files
It says

"When an archive is being created, the following actions are performed on the source files:

· Hash calculation to ensure data integrity;

· Compression;

· Encryption.



When files are being extracted from the encrypted archive, the following actions are performed on the archive:

· Decryption;

· Decompression;

· Hash calculation for checking data integrity. "


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.

I wonder why both SHA-* amd RIPEMD are used-doesn't any one suffice?


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.


"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.


"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.


The sender and receiver will need to agree on a common seed for MT****7-so that they can calculate all consequent IV's .
By a simple linear transformation MT****7 becomes a linear recurring sequence.If the attacker gets hold of enough number of IV's he will be
able to predict future IV's and to make them secure they needed to be
initially hashed using a hashing algorithm like SHA and then used as
IV for CBC mode.Then a PRNG like Taus88 with a period of nearly 2^80 would suffice.It is also faster than MT****7 and uses a much smaller working space as well as a sufficiently large period.

If the derived IV is just saved with the archive-it would be necessary to initially hash the plain text to detect corruption since block replay attacks can be successfully implemented if it is the compressed text that is hashed.


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.


Regards Data.

Hi Data,

[QUOTE]
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.
[/QUOTE]

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.

[QUOTE]
I wonder why both SHA-* amd RIPEMD are used-doesn't any one suffice?[/QUOTE]

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.


[QUOTE]
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.
[/QUOTE]

Can't say anything about it, I'm not a professional cryptanalyst:-)

[QUOTE]
"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.[/QUOTE]

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.

[QUOTE]
"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.[/QUOTE]

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.

[QUOTE]
The sender and receiver will need to agree on a common seed for MT****7-so that they can calculate all consequent IV's .[/QUOTE]

Then a common seed would be visible to the interceptor. Doesn't make difference.


[QUOTE]
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.
[/QUOTE]

I fully agree with you on this one.

Regards,

MrByte

hi,

thank you for the reply.

[QUOTE]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.[/QUOTE]

There may be an even better way.All we need is to add some salt at the end of the pass phrase and hash it,we can use MT here for generating some noise.Then one SHA round would suffice to produce the key and the cryptanalyst learns nothing more and is also secure from dictinary attacks.Block operations like those in SHA also have the property that even a change in one bit of the input will bring about a change in half of the message digest.

Just a s***estion,wouldn't really make much of a difference when computers are so fast.



[QUOTE]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.[/QUOTE]

Yes we cant decrypt without the IV's but if the IV is just appended to the archive,the attacker can use this IV and derive the original cipher text and he can suceessfully perform block replay attacks on the cipher text.


[QUOTE]Then a common seed would be visible to the interceptor. Doesn't make difference.[/QUOTE]


Just like in digisecret the pass phrase to be communicated with the receiver to decrypt the text,the common seed also should be shared. MT****7 has a period of 2^****7-just one shared seed will be able to generate enough IV's for many years.Since mt's sequence is equivalent to a LFSR implementation-given enough IV's the attacker can predict the sequence.So theses IV's should be hashed and the hashed IV's need to be used as the derived IV for cbc mode.
If the derived IV is just appended some place the attacker can still perform the block replay and the purpose if using an IV itself is beaten.

More over a smaller period generator like Taus 88 would do instead of MT. 2^80 IV's which is the period of the generator should be sufficient for an application for a life time.



Regards Data.

hi,

[QUOTE]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.[/QUOTE]

Yes,my bad. One of my wierd thoughts got me wrong :rolleyes:

Regards Data.