crypto confusion & snake oil

Encouraging best practices in the VPN industry via independent, community-certified verification of clean installers and clean basic service operations. Let's reward the good, and make the bad a little bit less tempting 〰 github repo#cleanVPN
User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am

1024 RSA declared "dead"... in 2007

Post by Pattern_Juggled » Mon Sep 09, 2013 7:08 pm

Researchers: 307-digit key crack endangers 1024-bit RSA
Jacqui Cheng | May 23 2007, 3:37pm PDT | Ars Technica

A 307-digit composite Mersenne number has been broken down into primes, and 1024-bit RSA keys are next, according to encryption researchers. Researchers from the University of Lausanne, the University of Bonn, and NTT DoCoMo have broken a new record in discovering the prime factors of a "special" 307-digit number this month, which took 11 months and roughly 100 years of computer time. The number was cracked using the special number field sieve method developed by cryptology professor Arjen Lenstra in the 1980s.

The 307-digit number itself was not an RSA key—the number was 21039-1, a special-form number called a Mersenne number which permits an efficient variant of the factoring algorithm in question, the so called Special Number Field Sieve (SNFS) to be used. RSA keys are typically generated by multiplying together two very large prime numbers, each at around 150 digits apiece, and require more labor-intensive General Number Field Sieve (GNFS) to factor. But the project shows that given enough time and computer power, the 1024-bit encryption keys used on many e-commerce sites could also be cracked in the not-so-distant future.

"Last time, it took nine years for us to generalize from a special to a nonspecial, hard-to-factor number," Lenstra said in a statement, referring to a 155-digit number that his team had broken previously. More recently, a 200-digit non-special number was factored in 18 months and roughly 50 years of computer time. This 307-digit crack took even less (human) time, which Lenstra credits to more powerful computers and improved code. "I will not make predictions [about the future of 1024-bit encryption], but let us just say that it might be a good idea to stay tuned."

Why does anyone care? While your average Joe or Jane on the street will not be able to crack a 1024-bit RSA key anytime soon, experienced attackers might not have such a hard time. Getting the computing power to crack a 1024-bit key could be as easy as employing a decent-sized botnet or two.

When asked whether 1024-bit RSA keys are dead, Lenstra said: "The answer to that question is an unqualified yes." Hopefully, my bank is paying attention to these developments.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github


Re: crypto confusion & snake oil

Post by jannyw4011 » Sat Nov 21, 2015 1:48 pm

LimeVPN does everything a customer wants to exceed the customer requirement of accessing blocked internet content, from high speed to data security, integrated into its VPN services.


Re: crypto confusion & snake oil

Post by PIAd » Sun Jan 22, 2017 7:19 pm

As a long time PIA user, I bring proof that it is now snake oil:

If you download the "strong" config:
WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1542'
WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'
WARNING: 'auth' is used inconsistently, local='auth SHA256', remote='auth SHA1'
WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
They have finally replaced their previous default, a blowfish, config with 128, although still provide it as "legacy" config:
WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
This is not a secure default at ALL!

Posts: 3
Joined: Sun Jan 13, 2019 8:56 pm

Re: crypto confusion & snake oil

Post by cygnus-x1 » Fri Feb 08, 2019 3:47 pm

It was reported on the Bugtraq mailing list in 2002, that Cypherpunk Lucky Green had revoked all his 1024-bit keys!

Lucky Green on the Bugtraq Mailing List

From: Lucky Green (
Date: Sat Mar 23 2002 - 19:38:02 CST ... /0306.html

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

As those of you who have discussed RSA keys size requirements with me
over the years will attest to, I always held that 1024-bit RSA keys
could not be factored by anyone, including the NSA, unless the opponent
had devised novel improvements to the theory of factoring large
composites unknown in the open literature. I considered this to be
possible, but highly unlikely. In short, I believed that users' desires
for keys larger than 1024-bits were mostly driven by a vague feeling
that "larger must be better" in some cases, and by downright paranoia in
other cases. I was mistaken.

Based upon requests voiced by a number of attendees to this year's
Financial Cryptography conference <http:/>, I assembled and
moderated a panel titled "RSA Factoring: Do We Need Larger Keys?". The
panel explored the implications of Bernstein's widely discussed
"Circuits for Integer Factorization: a Proposal".

Although the full implications of the proposal were not necessarily
immediately apparent in the first few days following Bernstein's
publication, the incremental improvements to parts of NFS outlined in
the proposal turn out to carry significant practical security
implications impacting the overwhelming majority of deployed systems
utilizing RSA or DH as the public key algorithms.

Coincidentally, the day before the panel, Nicko van Someren announced at
the FC02 rump session that his team had built software which can factor
512-bit RSA keys in 6 weeks using only hardware they already had in the

A very interesting result, indeed. (While 512-bit keys had been broken
before, the feasibility of factoring 512-bit keys on just the computers
sitting around an office was news at least to me).

The panel, consisting of Ian Goldberg and Nicko van Someren, put forth
the following rough first estimates:

While the interconnections required by Bernstein's proposed architecture
add a non-trivial level of complexity, as Bruce Schneier correctly
pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA
factoring device can likely be built using only commercially available
technology for a price range of several hundred million dollars to about
1 billion dollars. Costs may well drop lower if one has the use of a
chip fab. It is a matter of public record that the NSA as well as the
Chinese, Russian, French, and many other intelligence agencies all
operate their own fabs.

Some may consider a price tag potentially reaching $1B prohibitive. One
should keep in mind that the NRO regularly launches SIGINT satellites
costing close to $2B each. Would the NSA have built a device at less
than half the cost of one of their satellites to be able to decipher the
interception data obtained via many such satellites? The NSA would have
to be derelict of duty to not have done so.

Bernstein's machine, once built, will have power requirements in the MW
to operate, but in return will be able to break a 1024-bit RSA or DH key
in seconds to minutes. Even under the most optimistic estimates for
present-day PKI adoption, the inescapable conclusion is that the NSA,
its major foreign intelligence counterparts, and any foreign commercial
competitors provided with commercial intelligence by their national
intelligence services have the ability to break on demand any and all
1024-bit public keys.

The security implications of a practical breakability of 1024-bit RSA
and DH keys are staggering, since of the following systems as currently
deployed tend to utilize keys larger than 1024-bits:

- IPSec

An opponent capable of breaking all of the above will have access to
virtually any corporate or private communications and services that are
connected to the Internet.

The most sensible recommendation in response to these findings at this
time is to upgraded your security infrastructure to utilize 2048-bit
user keys at the next convenient opportunity. Certificate Authorities
may wish to investigate larger keys as appropriate. Some CA's, such as
those used to protect digital satellite content in Europe, have already
moved to 4096-bit root keys.

Undoubtedly, many vendors and their captive security consultants will
rush to publish countless "reasons" why nobody is able to build such a
device, would ever want to build such a device, could never obtain a
sufficient number of chips for such a device, or simply should use that
vendor's "unbreakable virtual onetime pad" technology instead.

While the latter doesn't warrant comment, one question to ask
spokespersons pitching the former is "what key size is the majority of
your customers using with your security product"? Having worked in this
industry for over a decade, I can state without qualification that
anybody other than perhaps some of the HSM vendors would be misinformed
if they claimed that the majority - or even a sizable minority - of
their customers have deployed key sizes larger than 1024-bits through
their organization. Which is not surprising, since many vendor offerings
fail to support larger keys.

In light of the above, I reluctantly revoked all my personal 1024-bit
PGP keys and the large web-of-trust that these keys have acquired over
time. The keys should be considered compromised. The revoked keys and my
new keys are attached below.

--Lucky Green

Post Reply