[Crypto Protocol Evaluation] Increased Protection or Snake Oil?

Hi,

I'm currently writing an app, designed primarily for file encryption so that files can either be archived or transmitted securely.

The files are being secured with a cascade of symmetric ciphers (TwoFish, AES and Blowfish).

My first question relates to the password used for the encryption. I'm only asking for a single password, but that password is modified and used in the following way (pseudo-code):


The actual encryption only occurs once for each algorithm. Using a single password, but with the above steps, is this a snake oil approach, or would it actually help? I've read that hashing multiple times helps to strengthen the hash, but in this context, I'm not so sure it would make a difference. Add to that the fact that the source is a single password, is this system flawed, or given the hashing, or would it actually stand quite well??

Because the actual password and IV being used for the encryption is based on the hash output, would the actual strength of the password would be equal to one iteration of the hash?



I'm also working on the key management, and wondered whether there was any advantage to the following:

Signature(SHA512(Public Key))

So the Public (or Private) Key is hashed along with some user data (OU, Country etc) to create a certificate file, then all of the above is signed.

I was considering the following scenario:

User A signs public certificate and sends to User B.

Attacker intercepts key, changes public key component, and re-signs with their private key. HOWEVER: The attacker was very clever and found a collision, so the signature looks identical.

I was thinking that by including a hash, an attacker would also have to find a collision for the same data in another hash at the same time.

Finally, I'm using a SHA1 hash of just the public key, to create a key ID.

In order to successfully defeat the system, 3 hashes would have to provide the same output for two different sets of data at the same time.

The actual file is structured:



Any feedback welcome. At this time the system is incompatible with anything else, but I'm looking at including compatibility with OpenSSL by enabling DER encoded certificates to be exported/imported.

Best regards,
AstroTux.

As I wrote in another thread, I don't see why you are using three ciphers. Just use one.

You have not explained how you use the public keys.
There is a standard approach that you should use.

Hi,

The only reason I'm cascading 3 ciphers is to try and help mitigate against the possibility that one or more of them could be broken, or an efficient attack method found, that enables data encrypted with it to become vulnerable.

It sounds like a long time, but some of the data I've come across has been in use for over 20 years. It is quite conceivable that that data could be in use for another 20, and data going on those systems today could be around in 40 years time.

I need something that I can be reasonably happy will survive at least that long.

My goal is to protect data for at least 50 years (even if it seems OTT to do so).


My apologies.

The public keys are used for encrypting the keys used for the symmetric encryption. The private key is used to sign itself (is there any point in doing that?) and the public key, and the public key is using itself to verify its digital signature (hence the part about using hashes, too, to help mitigate against possible collisions).


In what respect? From what I've been reading, it is generally accepted that data is encrypted with block ciphers, not least because they're quicker, then their keys are encrypted with the public key of the recipient. The data and encrypted keys are then transmitted.

Best regards,
AstroTux.

Well, I could see AES and Blowfish, so I guess a third might help. I'd not use a *fish, but rather something from some other cryptographer.




There is really no value in signing the private keys.
There is some value in signing public keys, but there is more value as the keys are signed farther away.

Standard practice is to calculate a HMAC and sign that.





Right, normal practice is to generate a random nonce
and use RSA to encipher it, send it to the other guy (bob). Then use the nonce as the IV and key for the block chains. Generate lots of bits, use some for the IV for one cipher, some for the key, repeat as needed.

Then bundle the cipher text and send it.

You may want to use OAEP on the blocks of the session key under RSA.

RIGHT! Thanks for clarifying that point! I'd read this elsewhere, but for some reason it just wasn't going in.

I can ditch my user input for the key now, too.


OK!


OK.


So calculate HMAC for the key, then sign the key and the HMAC?

Is the Windows PRNG as good a source as any for random bit generation, or do you recommend using another, proven design?


Hmm. Any recommendations?

Thanks for your input - greatly appreciated!

Best regards,
AstroTux.

Take a look at TrueCrypt mate, might help you with your symmetric encryption queries (google etc)

Theres nothing really wrong with using *fish'es, thats just his opinion. Of course its completely possible to use other ciphers such as serpent (I'd going looking straight at the AES candidates), but we'll never know which ones will be broken in 20 years time until then

My goal is to be lying on a beach somewhere, perhaps even in Au, in 20 years, so its someone else's problem.

Its hard to find a solid engineering base to use much more than AES256, but if you are paranoid, they may really be out to get you.

Hi,

Good luck on your goal! As Bruce Schneier said: "The best kept secrets are those that don't exist". I just want to make sure I don't go breaking any laws on description of goods etc..


I'd like some clarification on this, please. I'll hopefully get some time this weekend to research HMAC.

Best regards,
AstroTux.

If you only need 50 years, you might want to check out the official NIS&T recommendations. In this case, NIS&T is really just the public arm of NSA. So while the NSA knows its stuff, you might not want to trust their recommendations.

http://www.keylength.com/en/4/
from now until 2030, they say AES-128 with RSA 2048

For later than 2030, they say AES-128 with RSA 3072

They have suggestions for way past 2030, but I don't know how far out that really means.

Hi,

Interesting... are those times an extrapolation of the time required to factor 1023-bit keys, not allowing for increases in computer performance do you know?


Is that a suggestion or a comment?

If they're suggesting that a 3072-bit key is only good until 2030 (i.e. just 22 years from now), and we know they've just factored all 1023-bit keys, does this mean that at the present rate we need to be increasing key-length by 1024-bits every 10 years at a minimum, in order to stay ahead of progress?

Does that mean todays 4096-bit keys are only good for 32 years (the year 2040), or have I mis-calculated?

Best regards,
AstroTux.

NSA assumes Moore's law. They understand computers. Alan Turing, who provided the theory behind modern computers was a cryptographer in the British equivalent to the NSA during WW2.




The best cryptographers in the world work for National Security agencies. NSA is ours. They knew about differential analysis to exploit DES at least a decade before anyone else did.

Check Wikipedia for "Data Encryption Standard" There have long been rumors that NSA designed DES specifically to be strong enough to look good, but weak enough for them to break.

This is a complex topic, you should follow some of the links and make informed judgments.

The paranoid might think that I work for the NSA and am misleading folks....