Re: Unbreakable Encryption ? Scenarios - What encryption method would be best?

From: AE (hidden_at_nospam.com)
Date: 03/16/04 

Date: Tue, 16 Mar 2004 20:05:27 +0100

anon wrote:
> AE wrote:
>>>...
>>>1. A user has a bunch of files (they could all become one file via
>>>compression in a .zip like container) and the user wants them to be
>>>encrypted so that it is impossible (or would take an insanely large
>>>amount of time, i.e. till the end of time) to crack. The user plans to
>>>decrypt the files when the user needs to access them and then encrypt
>>>them when the user is not using them. What would be the most secure
>>>method of encryption?
>>
>>I'd say encryption itself is the least problem - use 3DES or blowfish or
>>AES128 or Camellia128 in CBC mode or even ARCFOUR with unique nounces -
>>but you have to use strong keys and you have to wipe the plaintext
>>securely from your harddisk. It's hard to remember a password with
>>sufficient enthropy (a problem that can be reduced but not solved using
>>password strengthening) so it might be better to store the key on a
>>floppy disk or a usb stick. But what if this key gets stolen or simply
>>lost? In the one case you'll need additional authentication (maybe a
>>password to protect the key), in the other case you'll need a backup of
>>the key - but where to store it securely?
>
> So out of all the avalible encryption methods there are none that
> signficantly differ in strength?

All of them are beyond what you'll need.

For sufficient security you should target an effective keysize of about
80bit.

3DES is the one with the smallest effective keysize - about 112bit (use
it anyway with 168 bit keysize). The most effective attack against 3DES
even reduces this, but even then it is is good enough. On the other hand
DES is a well-known algorithm so there are good reasons to have a good
feeling when using this algorithm.

AES and the improved version Camellia are stronger with a keysize of
128bit, but they are much newer and there might be attacks faster than
exhaustive search.

Blowfish with it's 448 bit keysize and high security margins is surely
most impressive, but who knows what future attacks might be like?

> Is there a difference between someone
> using 3DES vs blowfish for example, if so what is the hardest to
> crack? if there is no hardest to crack, what do you think would be the
> hardest for a third party to decrypt and why.

I'd guess blowfish will be the strongest due to the design principle: It
was designed with the idea not to go any risk while DES was designed to
be efficient on hardware and AES and Camellia were designed to be
efficient on any platform from hardware to 32bit computers.

But the point is that none of them can be broken with anything we know
and we don't know what future attacks will look like.

> Say the user wanted to
> risk it by storing one of the best possible passwords (or encryption
> key I think, in this case) on a CD-R. There would be ~700MB to work
> with as far as storing passwords, what would be the strongest
> encryption with a gigantic password? I know if the cd is found then
> its all over but is there an encryption method out there that would be
> uncrackable w/o the CD-R? If so what is it.

See above. If somebody really wants to decrypt the message he will more
likely steal the CD or force you to hand it out. Or he will install a
trojan horse on your computer or trap the room where it is or read what
you are reading using the radio emissions from your monitor or video card.

>>PGP and GnuPG are supporting symmetric encryption for this purpose, but
>>there are countless other solutions.
> ...
>
> Symmetric encryption doesent sound very safe, with computers getting
> faster and faster that millennia could turn into hours.

This is as well true for asymmetric algorithms. All algorithms mentioned
  won't be broken within the next decades if nothing very surprising
happens.

>>>2. User A wants a way to send a single message to user B using the
>>>most secure method of encryption. What would be the most secure method
>>>of encryption?
>>
>>This depends on whether there is a secure channel to exchange keys or
>>not. The problem is reduced to problem 1 in case this way exists.
>
> Ok lets say there will be a secure channel but it will happen only
> once a year. Could person A be equipt with an encoding method used to
> send messages to person B and a decoding method used to decode
> messages from person B and person B be equpt with an encoding method
> used to send messages to person A and a decrypting method used to
> decrypt messages from person A. So there would be public communication
> between the two, lets say email for instance, would the messages
> remain secure unless one of the decrypting methods was found? The
> encrypting/decrypting methods would not change, numerous emails would
> be sent using the same ones.

As long as there are only these two people I'd suggest to use your
algorithm of choice to encrypt a message key and use this key to
transmit the message. This way only small amounts of data (the message
keys) are encrypted with the long-living key.

Don't forget not only to encrypt but as well to authenticate the messages.

>>Else the problem is how to be sure one is speaking with the right person
>>and not impersonated by somebody else. There are solutions like PGP's
>>web of trust or the tree of trust used by X509.
>
> In my new example wouldent person A be able to verifie person B
> because the decrypting method yielded a plain text message and vice
> versa? If someone intercepted the encrypting and or decrypting methods
> things would get messy very quickly but privoded they are secure would
> it still be alright?

In your new example this would be possible, but only due to the secure
channel.

>>For general purpose I'd suggest to use PGP or GnuPG or PEM.
>
> Can we pretend for the sake of education that in my example the data
> being transfered is highly classified and secuirty is the top
> priority?

If you are able to exchange public keys in a secure way and you are
using asymmetric keysizes of 2048 bit or more you are on the secure side.

>>>3. User A wants a way to enable secure communication from user A to
>>>user B so that third parties can not read the communications. What
>>>would be the most secure method of encryption?
>>
>>This is more or less the same as problem 2.
>
> Kind of, problem two delt with a single message and this deals with
> multiple messages, I am under the impression that the number of
> messages sent using the same methods had an impact on secuirty.

The same method is ok. If you are able to change keys from time to time
or (even better) from message to message you should do that.

>>In addition you should use something to exchange keys securely so only
>>the key used for authentication is used long-term.
>
> Is it bad to reuse the same method of encryption/decryption provided
> that they are secure and the only data that can be found by third
> partys is the encrypted text?

No.

>>Depending on your needs you should use either PGP/GnuPG or SSL/OpenSSL.
>
> I've read a little bit about each, PGP seems (to me) like a secure
> encryption style for emails while SSL applys to webpage datatransfer.
> Are there really no superior encryption methods that stand above the
> others?

There are secret algorithms used by governments, but it is much more
dangerous to develop one's own algorithm than to use one of the
algorithms tested by experienced cryptographers.

Right the same for protocols: Use well known and well tested protocols.

> Or do they all do somewhat the same thing but because of the
> way they do it each has different weaknesses and strengths?

 From the cryptographic point of view they are more or less the same -
digital signatures for entity authentication (a person or a webserver),
key-exchange-algorithms, short living keys for symmetric encryption and
message-authentication. The main difference is the trust-model.

> If that is the case I'll have a lot of reading to do.

Yes - that's a good idea. Maybe you should start with "Secrets and Lies"
by Bruce Schneier.

> Thank you for your time!

You are quite welcome.

Relevant Pages

  • Re: [fw-wiz] Re: Firewalls breaking stuff: [Was re: fwtk]
    ... > access to the mail server's private keys and thus the monitor can follow the ... > in a way that's more secure rather than less secure. ... for service level encryption versus VPN access. ... >> reducing bugs reduces the number of sever bugs. ...
    (Firewall-Wizards)
  • Re: Best secure surfing solution
    ... I have set up a service with companies providing secure web ... the product would have to install a keylogger. ... If we caught anyone in> IS or elsewhere in our company sniffing our communications, even if they> were encrypted, they'd get laid off or, at least, suspended. ... If e-mails are sensitive then> the sender should be using encryption. ...
    (sci.crypt)
  • Re: Best secure surfing solution
    ... I have set up a service with companies providing secure web ... the product would have to install a keylogger. ... If we caught anyone in> IS or elsewhere in our company sniffing our communications, even if they> were encrypted, they'd get laid off or, at least, suspended. ... If e-mails are sensitive then> the sender should be using encryption. ...
    (alt.computer.security)
  • Re: Insecure cryptographic algorithms to avoid using?
    ... encrypt some user passwords. ... You have an algorithm that is known to work. ... be insecure fundamentally or inadequately secure due to key length as ... However, encryption and security ...
    (sci.crypt)
  • Re: Symmetric encryption algorithm with group like properties
    ... >> Solutions that exist today are not as secure as they can be. ... I wouldn't expect more than PGP / GPG type encryption, ... > versions - with the key, protected by RSA encryption under a RSA public key ... > Alice needs a secure decryption mechanism to read her emails, ...
    (sci.crypt)