RSA public key

[jj2007]

You could be surprised of how difficult it can be to have a computer produce 'good enough' random data.

I believe you :toothy

Some years ago somebody played with the idea of using the 2 seconds delay between a message exchanged between two points on Earth and another one sent from Earth to the Moon and back for safely transmitting an OTP. But I can't remember the details...

[Astro]

Yes, I read it today.
There is one thing that needs to be clarified. And that is the meaning of the word 'broken' in this context.

Before saying that RSA-768 is unbroken, we should consider that they made over 5TB of rainbow tables, and now its a matter of a lookup, which will take minutes to hours. Imho i dont condider RSA-768 unbroken in its vanilla (RFC) form. Now that they've done this, what's the next keysize to fall? I seriously doubt that organizations like the NSA would have a problem with 100TB, 1000TB worth of HDD and the mind boggles at the computational power they could lay their hands on if they want to build insane sized tables.

Also the fact it was broken once, irrespective of MIPS time taken, means it has been broken and will be again.

HR,
Ghandi

Absolutely right.

The hard work is done, and now they know every possible key for 768-bit RSA. It is just a matter of trying every key with the ciphertext.

You are ill-advised to continue using it.

Bruce Schneier thinks 1024-bit will be factored within 5-8 years.

Use 4096-bit or longer for serious use. The whole point is for the data to be worthless/useless at the time it is recovered. If your data is OK to be exposed in 5 years time, then 1024-bit will be fine, otherwise you need something stronger. It is also recommended to build in a bit of "extra time" into the life of your keys anyway to allow for progress in the field.

All of the above assumes there is no faster way to factor primes than is currently known (not including more/faster computers).

Best regards,
Robin.

[caraveiro]

Back to the original topic:

See rsa.cpp from the library!

http://www.cryptopp.com/

[Astro]

if you create your own, your encrypted stuff stays secret for longer.

Not true, unless you really do hit on The Next Big Thing.

Eddys site worries me a bit - he states on one of his pages that you can "access an internet server for truely random data".

1) Who owns the server?

2) What is the source of the "truely random" data?

3) Isn't the 'net insecure, and thus no good for obtaining key material?

Crypto systems security always collapses to the strength of the weakest link, and I certainly wouldn't be trusting the result of some unknown server.

Fact: nearly all crypto systems are "broken" via some problem with the random number generator. To have a true break requires the algorithm itself to be flawed.

Best regards,
Robin.

[Eddy]

1) Who owns the server?
2) What is the source of the "truely random" data?

Hi Robin,
The site that this particular HIME function retrieves the random data from is http://www.random.org/. You can find the answer to your questions there.

3) Isn't the 'net insecure, and thus no good for obtaining key material?

Very true. That's why I specifically state in the HIME help file:

Since the random data is retrieved over an insecure channel, it is not a good idea to use the data as-is for a session key or a password. You should use some kind of scrambling algorithm before using it for security purposes.

Random data retrieved from that server should not be directly used for security purposes. It can be useful for experiments though.
For generating key material, I recommend using the HIME Blum-Blum-Shub PRNG or the RSA PRNG.

Fact: nearly all crypto systems are "broken" via some problem with the random number generator.

That's why I always suggest using the Blum-Blum-Shub PRNG. That is probably the best software PRNG around. If you need better, you'll have to use a hardware RNG.

Kind regards

[Don57]

I've working in research most of my life. Iin the late 70's I read a paper by two researchers, who were doing prime number research, and cracked RSA 512. That was almost 35 years ago, who knows where the NSA is now. So RSA would not be my choice.

[Eddy]

Don,

Yes, the NSA could crack 'xxx-bits' RSA if they want to. But this would require a lot of computing capacity. Computing capacity they have a shortage of.
Nowadays, 2048 or 4096 bits RSA is fairly common. This, even for NSA, requires an enormous amount of calculating power to (try to) decrypt.
So, the question you have to ask yourself is: Is the information that I want to encrypt potentially SO valuable to the NSA that they want to spend a large piece of their computing capacity trying to decrypt it ..?
Also, you can make it a lot harder for them, if you encrypt two (or more) times in a row. That way, the plaintext of the last encryption is not readable text but ciphertext of the previous encryption round. So, how do 'they' know if they have decrypted your (outer) ciphertext correctly..?
Oops ... hope this 'tip' doesn't get me blacklisted with NSA ...  :eek   :bg

Kind regards
Eddy

[Tedd]

Use TLS (Transport Layer Security) - this is what it's designed for.
Don't make the mistake of assuming your own implementation and/or algorithm will somehow be more secure - it won't.


RSA is believed to be secure based on the difficulty of factoring integers, and that no-one (publicly) knows of any better way to do it. (There are various shortcuts based on certain forms of numbers, but in general it's a difficult problem.) So, while you could fill a room with terabyte drives and fill them with 'rainbow tables,' it quickly becomes pointless. You get to a point where the mass of your storage array has so much mass that it collapses into a black-hole.

[Don57]

Here's an interesting page


http://www.kremlinencrypt.com/algorithms.htm