A friend of mine told me that 1024bit keys were broken, and he advised me to use 4096bit keys... I think he is confusing ssl with ssh. Do you have similar information on this? Praise
While it is true it is possible to break an 1024bit key, it is also difficult. While I am not saying that going to an higher bit key is a bad idea it is also proabably not really necessary. Also ssh is based on ssl so what effects one (as far as keys) effects the other. Austin Morgan On Mon, Jul 01, 2002 at 06:23:45PM +0200, Praise wrote:
A friend of mine told me that 1024bit keys were broken, and he advised me to use 4096bit keys... I think he is confusing ssl with ssh. Do you have similar information on this?
Praise
On Mon, Jul 01, 2002 at 06:23:45PM +0200, Praise wrote:
A friend of mine told me that 1024bit keys were broken, and he advised me to use 4096bit keys... I think he is confusing ssl with ssh. Do you have similar information on this?
There is a paper by Dan Bernstein that discusses how much computing power (and money) it would take to build something that's able to brute force a 1024 bit RSA key. Based on this paper, I believe, some people recently drew the conclusion that you can build such a thing for 1 billion USD which should be well within the budget of several US government agencies. None of this is proven, and pretty much of this is based on speculation. This is, to my knowledge, what this entire "stop using 1024 bit RSA keys" discussion is based upon. Whether you consider this a serious threat greatly depends on your personal paranoia quotient when it comes to said US government agencies. My personal opinion is, there's no need to panic, and throw away all your keys. If you do create a new key, it is a good idea to choose a bigger key length if the software supports it. Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann
* Olaf Kirch wrote on Tue, Jul 02, 2002 at 09:18 +0200:
On Mon, Jul 01, 2002 at 06:23:45PM +0200, Praise wrote:
A friend of mine told me that 1024bit keys were broken, and he advised me to use 4096bit keys... I think he is confusing ssl with ssh. Do you have similar information on this?
There is a paper by Dan Bernstein that discusses how much computing power (and money) it would take to build something that's able to brute force a 1024 bit RSA key.
Based on this paper, I believe, some people recently drew the conclusion that you can build such a thing for 1 billion USD which should be well within the budget of several US government agencies. None of this is proven, and pretty much of this is based on speculation.
IIRC there were other people who told that DJB missed some details and the costs would be even larger.
My personal opinion is, there's no need to panic, and throw away all your keys. If you do create a new key, it is a good idea to choose a bigger key length if the software supports it.
Well, and if you do not trust 1024 Bit, I really wonder why someone should upgrade to 4096 bit. IIRC adding tree bits or so of length would statistical double the needed break time. In that case, going from 1024 to 4096 bit would double 1024 times, that is 2^1024 (and not 2*1024!) which evaluates to 17976931348623159077293051907890247336179769789423065727343008115773\ 26758055009631327084773224075360211201138798713933576587897688144166\ 22492847430639474124377767893424865485276302219601246094119453082952\ 08500576883815068234246288147391311054082723716335051068458629823994\ 7245938479716304835356329624224137216 times. So even 2048 bits are really paranoid - assumed some agency use weeks of computing power of the billion dollar machine to break *your* 1024 SSH/SSL/TLS RSA key... Please correct me if I'm wrong! From my today knowledge, german banks (who are known to have very high security standards) allow 1024 bit RSA for payment, and in the next years the key lengths get increased to 1152 Bits. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Yuppa, Steffen Dettmer wrote: [...]
Well, and if you do not trust 1024 Bit, I really wonder why someone should upgrade to 4096 bit. IIRC adding tree bits or so of length would statistical double the needed break time. In that case, going from 1024 to 4096 bit would double 1024 times, that is 2^1024 (and not 2*1024!) which evaluates to
17976931348623159077293051907890247336179769789423065727343008115773\ 26758055009631327084773224075360211201138798713933576587897688144166\ 22492847430639474124377767893424865485276302219601246094119453082952\ 08500576883815068234246288147391311054082723716335051068458629823994\ 7245938479716304835356329624224137216
times. So even 2048 bits are really paranoid - assumed some agency use weeks of computing power of the billion dollar machine to break *your* 1024 SSH/SSL/TLS RSA key..
Quite right. On the other hand, I wouldn't even bet on a 2048 bit key in the wake of recent efforts (and steps forward) in quantum computing, but that's prolly just me. Fact is that good intelligence can be obtained by traffic analysis alone. In most cases, it's not necessary to brute-force into an encrypted message, so the key size alone is a good, but not the only factor in this "game". My $1. Could I have change, please. Boris ---
On Tue, 2 Jul 2002, Boris Lorenz wrote:
Yuppa,
times. So even 2048 bits are really paranoid - assumed some agency use weeks of computing power of the billion dollar machine to break *your* 1024 SSH/SSL/TLS RSA key..
Quite right. On the other hand, I wouldn't even bet on a 2048 bit key in the wake of recent efforts (and steps forward) in quantum computing, but that's prolly just me.
There have been big steps in quantum computing, but it's far from usable. At the moment it's still hard to create something like a five bit computer with AND and OR gates. And there is no chance to initialize a quantum computer with 10kb (normal size of a secret email) , as you have to load the complete document to decode. If this will be possible, all normal ciphers will be out of date. Then just say good bye to it all.
Fact is that good intelligence can be obtained by traffic analysis alone. In most cases, it's not necessary to brute-force into an encrypted message, so the key size alone is a good, but not the only factor in this "game".
That is a real argument to increase the key size or change keys on a regular base. To prevent intelligent attacks to the key you should also hide the type of information that is transmitted (increasing entropy by sending nonsense). Michael Schmidt Icewolf
On Mon, Jul 01, 2002 at 06:23:45PM +0200, Praise wrote:
A friend of mine told me that 1024bit keys were broken, and he advised me to use 4096bit keys... I think he is confusing ssl with ssh. Do you have similar information on this?
There is a paper by Dan Bernstein that discusses how much computing
I do not believe my original message regarding this was sent.
Here are a few articles which discuss this issue:
http://www.rsasecurity.com/rsalabs/technotes/bernstein.html
http://www.networkcomputing.com/buzzcut/020412bc.html
http://www.vnunet.com/News/1130451
These provide some different views on the issue.
Here is a link to Bernstein's paper if you are mathematically inclinded:
http://cr.yp.to/papers.html#nfscircuit
I believe the real issue here is, do you have some secret which is worth
someone spending $1 billion (or even $100 million) to protect? If so, then
more power to you. Granted, the computing power to crack the key is
going to come about at some time in the future (as indicated in various
papers), for much less money. But cryptographic algorythms will be
improved at the same time. Seems that 1024 is strong enough for 99% of
its uses currently.
Just my 2 cents worth (can't even get a gum ball for that anymore).
Jim
7/2/2002 2:18:42 AM, Olaf Kirch
(and money) it would take to build something that's able to brute force a 1024 bit RSA key.
Based on this paper, I believe, some people recently drew the conclusion that you can build such a thing for 1 billion USD which should be well within the budget of several US government agencies. None of this is proven, and pretty much of this is based on speculation.
This is, to my knowledge, what this entire "stop using 1024 bit RSA keys" discussion is based upon. Whether you consider this a serious threat greatly depends on your personal paranoia quotient when it comes to said US government agencies.
My personal opinion is, there's no need to panic, and throw away all your keys. If you do create a new key, it is a good idea to choose a bigger key length if the software supports it.
Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Monday 01 July 2002 12:23 pm, you wrote:
A friend of mine told me that 1024bit keys were broken, and he advised me to use 4096bit keys... I think he is confusing ssl with ssh. Do you have similar information on this?
Praise
To give you an idea. June 1997, 56 bit DES key was cracked. August 1999, 512-bit RSA key was cracked. (At the time, 95% of the keys used in e-commerce were 512 bits long.) Recommended public-key key lengths (in bits) [Source: Bruce Schneider, Applied Cryptography] Year Individual Corporation Government 1995 768 1280 1536 2000 1024 1280 1536 2005 1280 1536 2048 2010 1280 1536 2048 2015 1536 2048 2048 Summary of Recent Cracking Efforts Algorithm Key Size Cracked on Duration RSA 425 1994 240 days RC4 40 8-95 8.5 days RC5 40 1-97 3.5 hours RC5 42 2-97 313 hours DES 56 6-97 140 days RC5 56 10-97 265 days DES 56 2-98 39 days -- Steve Szmidt V.P. Information Technology Video Group Distributors, Inc.
Hi, I am new to this list and I have a question concerning possible attacks on a webserver I am maintaining at my university. Regular checks of our logfiles turned up some strange requests coming from various IP addresses over the last week. They usually lasted for half an hour leaving the following entries in our logfiles: in /var/log/access_log: xxx.xxx.xxx.xxx - - [01/Jul/2002:19:24:51 +0200] "POST /index.php HTTP/1.1" 200 12781 ... (every 5 secs.) in /var/log/error_log: [Mon Jul 1 19:24:48 2002] [notice] child pid 877 exit signal Segmentation fault (11) ... (roughly 4000 segfaults altogether) The machine is running SuSE 7.3 with the following packages that may be related to these events: nue007:~ # rpm -q --all | grep "apache\|php" apache-devel-1.3.20-66 mod_php4-core-4.0.6-160 mod_php4-4.0.6-160 phpMyAdmin-2.2.0-21 apache-doc-1.3.20-66 apache-1.3.20-66 Perhaps this is nothing to worry about, but I was not sure and had a look on the internet. I assumed a connection with the PHP file upload vulnerabilities and exploits as discussed in http://www.cert.org/advisories/CA-2002-05.html, http://lists.insecure.org/vuln-dev/2002/Mar/0025.html and http://lists2.suse.com/archive/suse-security/2002-Jun/0414.html but thought that these were already patched using the above packages as described in http://www.suse.de/de/support/security/2002_007_mod_php4_txt.html. Does anybody know if there are other explanations for these segfaults? Am I still vulnerable even after doing regular security updates of all packages? How can I find out if my machine has been hacked? Perhaps this information is available somewhere on the Internet, but I didn´t find anything and am hoping that someone on this list can give me a hint. Thanks in advance, Bastian
--On Dienstag, 2. Juli 2002 16:08 +0200 I wrote:
[...] Perhaps this is nothing to worry about, but I was not sure and had a look on the internet. I assumed a connection with the PHP file upload vulnerabilities and exploits as discussed in
http://www.cert.org/advisories/CA-2002-05.html, http://lists.insecure.org/vuln-dev/2002/Mar/0025.html and http://lists2.suse.com/archive/suse-security/2002-Jun/0414.html
but thought that these were already patched using the above packages as described in [...]
The third URL I listed is wrong and I have lost the right one - a cut&paste error, sorry! Bastian.
participants (9)
-
Austin Morgan -
Bastian Schmick -
Boris Lorenz -
James Bliss -
Michael Schmidt -
Olaf Kirch -
Praise -
Steffen Dettmer -
Steve