milan.kral at azet.sk
Mon Jan 26 08:56:41 CET 2015
On 16.01.2015 18:24, Robert J. Hansen wrote:
>> Funny... people told that as well with RSA key sizes which are
>> nowadays no longer considered enough... o.O
> Back in the early 1990s, a 1024-bit RSA key was believed to be unassailable.
> A 1024-bit key is still today considered unassailable... it just doesn't
> have anywhere near the security margin that we want. We advise at least
> 2048-bit keys to give us a comfortable margin, not because we believe
> people are breaking 1024-bit keys.
"A 1024-bit key is still today considered unassailable" depends on how
much do you value the security of your information.
For example according to
"We presented a new design for a custom-
built hardware implementation of the sieving step,
which relies on algorithms that are highly tuned for
the available technology. With appropriate settings of
the NFS parameters, this design reduces the cost of
sieving to about $10M (plus a one-time cost of $20M).
Recent works [14, 9] indicate that for these NFS pa-
rameters, the cost of the matrix step is even lower."
> To give an idea: for distributed.net to exhaust a 64-shannon keyspace
> took them about five years. They're currently working on exhausting a
> 72-shannon keyspace, which they project will take about 200 years.
> Exhausting an 80-shannon keyspace (about the same as a 1024-bit RSA key)
> would take about 5,000 years at that pace, or one year and 5,000 times
> the resources of distributed.net.
> 1024-bit crypto is still strong today. It's just not as strong as we'd
> like and we can do better with few side effects, so let's do better. :)
>> It's really disturbing to read such statements (i.e. "xxx bit
>> security level will be secure forever - except for quantum
>> computers)... it seems as nothing would have been learned from the
>> past :-/
> No one will ever exhaust a 128-shannon keyspace until we have
> large-scale quantum computers and a few decades in which to operate.
> No one will ever exhaust a 256-shannon keyspace. Ever.
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
More information about the Gnupg-devel