October 3rd, 2002, 13:33
I'm sometimes paranoid that every Email I send and Web site I visit can be monitored by some agencies and corporates.

I think even 1024-bit encryption can be easily cracked especially by thousands of government and military intelligence owned supercomputers exist underground.

:? :lol: :cry: :oops: :x :twisted:

October 3rd, 2002, 16:52
What is the safest encryption on this planet so far?

properly used one time pads.

you'll need a really good source of random data and you'll need a method to get a copy of the one time pad to the other person, but if you can do that correctly, one time pads are unbreakable.

if you can't use otp's for some reason, then AES w/ 4096 bit keys should keep you safe for ten years, maybe 20 if we're lucky.

I'm sometimes paranoid that every Email I send and Web site I visit can be monitored by some agencies and corporates.

that's not paranoia, that's reality.

the world is completely different when, instead of thinking to yourself "maybe someone will see what i do", you think "everyone will see what i do". just reminded me of my brother's site-

I think even 1024-bit encryption can be easily cracked especially by thousands of government and military intelligence owned supercomputers exist underground.

so? a black ops squad can make you disappear so fast you no one will remember you were ever there. and that power is not limited to the .gov either - just think of Jimmy Hoffa.

if my military is wasting my money breaking into my systems, i want my taxes back. all it would take is a gun to my head to get me to give them root on my systems. it's not like they'll find anything all that interesting there anyways - just what the .gov needs is a db full of my old love letters, job applications, 'd00d your l337' messages, etc etc.

besides, if you really wanna get paranoid, get paranoid about TEMPEST-type privacy disclosures. the best way to protect yourself and your information is to make yourself useful and well-known and fully disclose everything - you know, like the OpenBSD project.

October 3rd, 2002, 20:16
Nicely handled frisco as always. :D

October 7th, 2002, 16:59
One time pad's aren't even realistic for email as the pad itself would need to be of equal size and distributed securely, which if you could do this, you'd do with the email itself instead. A more logical approach would be to use one of the public algorithms that have been under scrutiny for sometime now and distribute your public key, but use a large key. It's true, 1024 bit keys are pretty weak now, but 2048 is still considered secure by today's standards. Because all cryptography relies on math equations being difficult it's entirely possible that all the public algorithms have been broken and we just don't know, but chances are, if someone who can break that sorta encryption is after you, you've got much bigger problems!! I'd say using gpg with 2048 or 4096 bit keys should be sufficient. Gpgme lets gpg be integrated into several email clients and some use gpg straight without any library help. Mutt and Sylpheed are good examples of gpg enabled clients.

I hope this helps.


PS. The new cryptogram from Bruce Schneier discusses theoretical weaknesses in AES and even the mighty Serpent.[/url]

October 7th, 2002, 23:48
FYI: many companies that do govt work like infosec or pen test require pgp encrypted with 4096 bits... food for thought ..... =)

October 8th, 2002, 14:54
There you go. I've been told by someone who worked for the DEA and has been certified in all areas of cryptology by the NSA (he spoke at my school) that said they laugh at pgp encrypted messages. However, I do recall the FBI having to use a hardware keylogger between the keyboard and the computer to capture pgp passwords to catch a mobster who was encrypting all his messages. So, with that said, I'd imagine only the NSA and a few other agencies have the power to defeat 4096 bit encryption. Like I said before, if someone who can crack 4096 bit encryption is after, your in a lot more trouble that whether or not someone knows what your typing!

hugh nicks
November 15th, 2002, 14:49
i'm just waiting for quantum encryption. until then, i'm just using the best login around

name : admin
password : admin

(no one would think i'd be that stupid, so they'd never try it!)

hold on one sec guys.....

(what....they what?....what the hell is a trojan horse?....)

gotta go! :o

February 5th, 2003, 21:58
Sorry to bring up an old topic, just thought I should say, if you are really paranoid and have some IMPORTANT files, do what I do, GnuPG + 4096 bit DSA key + 768 bit El Gamal key, then 448 blowfish, then bzip2, then rename it backup.bz2 :D

February 5th, 2003, 22:29
if you want you can look here for a comparison in encription

basically tells which are better than which

October 14th, 2003, 06:20
This is always an interesting question. In all actuality,
our aim of using the safest encryption possible is, in
essence, not practically possible. The typical answer
is the famed One-Time-Pad cryptosystem. It requires
a theoretical framework that we can't meet in the
conventional cryptographic world. There's no in-between
when it comes to this system. You either have an OTP,
or you don't. It's as simple as theory. If this theory is
met, then yes, you have an unbreakable system. Seems
simple enough, eh? You may ask, "Why not attempt using
this?" Perhaps my article, found here (, will prove
enlightening. For the sake of the era, let's exclude this
system from our pool of algorithmic selection.

Now, on to a more feasible answer. Far too often, you see
those who will preach that AES is the most secure algorithm
available. Alright, so there is nothing wrong with using this
cipher, for a couple reasons. Number one, it is the standard.
This is perhaps the most logical reason, as compatibility and
liability hold such a high precedence. Number two, and quite
significantly so, Rijndael was designed by two top notch
cryptographers, whose work I do admire and take much heed
to. For a quick reference, I have prepared a "pocket guide" to
Rijndael's security, in a nutshell (

However, AES doesn't impress me as much as say, Twofish
or Serpent, when it comes security conservation. For a more
detailed review of mine, in regards to block cipher comparisons,
peruse your way through this ( article.

My main argument will be between AES and Serpent, however,
let me comment that Twofish is, in my opinion, the most logical
compromise between the other two. You have the speed and
larger security margin, as opposed to AES. I recommend it.

Now, before I begin this argument, I know there will likely be
pressed hype in regards to the XSL attack schematics. Keep
in mind, although these attacks apply to both algorithms, they
are highly theoretical. There's no imminent reason to consider
these algorithms broken, in this aspect. With that said, let's
move along. For a quick juxtaposition of these two algorithms,
consider this note on their cryptanalytic value. An attack, known
during the AES selection process, covers about 70% of the
Rijndael algorithm, for a 128-bit key. When these attacks are
expanded for larger key sizes, that leaves us with around 5 rounds,
max, of security, with AES. However, at the time of selection, the
best attack on Serpent only covered 10 of the algorithm's robust
32 rounds. Overall, you could say that Serpent is giving you around
38.75% more security, based on the remaining security margin in
terms of rounds, respectively.

So, in my opinion, 256-bit Serpent is the most security-wise choice.
Why 256-bit? Refer here (, to discover why I advocate the
deployment of 128-bit security via 256-bit keys.

On a final note, I notice the consistent discussion of key sizes,
ranging from 1024-4096, which generally correspond to
asymmetric algorithms. Keep in mind that the actual data
encryption isn't (or shouldn't be) in question, when referring to
asymmetric algorithms - only key exchange. This is because
public-key algorithms are susceptible to chosen-plaintext
attacks. If C=E(P) and n denotes a set of plaintexts, consider that
an analyst only has to encrypt this set and compare this with C,
as P belongs in that set. Now, you won't be able to determine the
decryption key with this attack, but you can recover P. To solve
this potentially serious problem, you can pad messages with random
data, which causes identical messages to encrypt to different

Another downfall is encrypting small messages, m. Let's suppose
one of our exponents, e, equals 5. Now, if m is smaller than
the 5th root on our modulus, n, then we are faced with no modular
reduction, as m^e=m^5 < n. Now what does this mean, you ask? Well,
let's say all we want to encrypt is a 256-bit symmetric key. If we only
encrypt this as a 256-bit integer, we end up with a value that is much
smaller than the modulus. Again, no modular reduction. So, key
recovery becomes as simple as computing the 5th root of the encrypted
value. Padding is only one small solution. When all is said and done,
keeping structure to RSA values is of much more concern. You need a
way of diminishing this structure to the farthest extent possible.

However ironic, structure within this structure is not a cool thing.

There's always the infamous Man-in-the-Middle attack, or MITM,
of which can negate any security that the underlying symmetric
algorithm in the hybrid system may offer. Authentication,
authentication, and more authentication. Use it.

Even then, with RSA (the most likely choice), you are limited by
the modulus, n, as to the allowed size of the message you'd
like to encrypt.

So, of course, asymmetric cryptography isn't suitable for
message encryption, not only because of this, but because
it's significantly much slower, in juxtaposition with symmetric
cryptography. With these impracticalities, it seems you have
a flock of birds to kill, but only one stone this time. It is absurd
to compare symmetric and asymmetric key sizes after a certain
point, but, if you want to adhere to forcing an attacker to issue
2^128 steps in attacking the system, you're going to need a key
in excess of 3+ times larger than 2048-bit.

You asked what is the "safest" encryption? Well, with today's
current selection, Serpent and Twofish - in that order. If you
want the confidence of a tried-and-true algorithm, go with
Triple-DES. If you're not really sure and want to stay with
the mass appeal, stick with the standardized AES, to play it
"safe", but necessarily most secure.

Either way you look at it, you honestly don't need the huge
<insert_outrageously_large_key_size_here> keys. For the
vast majority of application, 128-bit level security will suffice.

Pardon the length, although I do hope it will shed some light
on the subject. Feel free to have me elaborate further, if any
would like.


October 14th, 2003, 08:18
Just so you know, there is a free email service called Hushmail that offers 2048 bit encryption. You only get 2 mb of space but if you do not want to set anything up yourself, you may want to give this a try.

hugh nicks
October 14th, 2003, 23:08
of course the other alternative is to treat email like a postcard. assume everyone will read it, and whatever sensitive material needs to be sent, should just be sent another way.

even though the vast majority of people know not to send money in the mail, they still do. they've really only themselves to blame.

bottom line, if you don't want others to see it, don't say it.


October 15th, 2003, 00:04
I use to worry about my e-mail being monitored but not anymore. It just too big a logistical challenge to do. There would have to be a monitoring program/device at every entry point to the internet. Its just not going to happen and even if they did somehow persuade all these ISP's/universities etc to do it, it would be too big to cover up. Then there is the challenge of having enough computing power to scan every email. Email scanning programs are only looking for key words and phrases so if you are worried about someone reading what you wrote they work out a code with the other person. The way they do it now is to monitor already suspected individuals and if you are already suspected a joke of the day email isn't going to get you in any worse trouble.