Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

PrivateInternetAccess.com: crypto confusion & snake oil

Post a reply

This question is a means of preventing automated form submissions by spambots.
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek: :angel: :clap: :crazy: :eh: :lolno: :problem: :shh: :shifty: :sick: :silent: :think: :thumbdown: :thumbup: :wave: :wtf: :yawn:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review

If you wish to attach one or more files enter the details below.

Expand view Topic review: PrivateInternetAccess.com: crypto confusion & snake oil

Re: PrivateInternetAccess.com: crypto confusion & snake oil

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 (shamrockcypherpunks.to)
Date: Sat Mar 23 2002 - 19:38:02 CST

http://archives.neohapsis.com/archives/ ... /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:/www.fc02.ai>, 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

Re: PrivateInternetAccess.com: crypto confusion & snake oil

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!

Re: PrivateInternetAccess.com: crypto confusion & snake oil

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.

1024 RSA declared "dead"... in 2007

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.

Re: PIA: crypto snake oil | comment

by Baneki » Mon Sep 09, 2013 4:42 pm

{echoed here from underlying post, for referential integrity check ~ admin}
1. 1024 bit DH keys have been considered too short for real-world deployment for years... long before the latest NSA revelations. Anyone using them in production systems is either reckless, or foolish, or both.

2. OpenVPN has no requirement that it "must be interoperable with all other OpenVPN protocol/versions" - that's a silly statement, as OpenVPN can itself be configured to require specific cipher selection, handshake protocols, and so on... none of which will interoperate with other ovpn.exe instances unless also configured as such. Further, ovpn.exe is not universally backwards-compatible to all earlier versions of same; making this a design requirement of the codebase would simply cripple it.

3. If you're going to push out ECC as part of the default cipher suites (in which part of the auth protocol, specifically? Ephemeral DH? Symmetric ciphers? Public key validation?), what's your selection criteria for curve class? Because, as we all know, the NIST standard for certain forms of "default" curve configuration are crippleware, NSA-generated. To roll out ECC without fully understanding this, and mitigating against it, is to crack wide open any resulting "crypto" deployed.

4. If you're distributing a closed-source OpenVPN-"based" client, and your code running server-side is obviously not subjected to independent code audit (binary or source), what does it mean to keep touting "open source" with regards to your system? How can anyone authenticate that your closed-source client binaries have anything to do with OpenVPN, let alone that they're not backdoored? Packet capture and analysis could - eventually - uncover some such trickery, but certainly not all...

5. Given that your Terms of Service explicitly state that you cooperate with all LEO requests - and have a NO TOLERANCE policy for all sorts of network activity by paying customers - does it matter what cipher suites you claim to be using, if your corporate policy is published to be congruent with cooperation with any request by the NSA - or any other law enforcement agency - for complete and unfettered backdoor access to all network data?

6. What value does certificate-based, public-key cryptography add to a "consumer" VPN service in the first place? Schneier explicitly suggests minimising reliance on public key technologies unless mandatory... and there's no mandatory use-case for it in this model. Why is it part of the model - simply because OpenVPN defaults to it?

7. Do you enforce CBC on streaming ciphers? What streaming ciphers are your current default provisions, and what historically have been your streaming cipher selection choices? Given the deep flaws in RC4 and other default options in earlier TLS versions, have you been relying on those tools historically? Are you currently?

8. Can you provide an example of an "open source PPTP implementation?" We're curious...


PrivateInternetAccess.com: crypto confusion & snake oil

by Baneki » Mon Sep 09, 2013 4:35 pm

On Encryption
Posted on September 7, 2013 by coderrr

From all the news, it appears that there is one thing clear: Nobody is certain as to the exact capabilities of the NSA, other than the NSA itself. However, as soon as the limited information was released, we began conducting research and were able to draw some conclusions. As of now, Bruce Schneier appears to be our best source of information in regard to this matter, as he is a security and cryptography expert, and often speaks in the defense of civil liberties. He has been given direct access to Snowden’s source NSA materials. As such, at this point he is the only one, on our side, that is in a position to make conclusive educated guesses about the NSA.

Dead or Alive

To begin, encryption, in general, is neither dead nor useless. Both Snowden and Schneier have made strong statements indicating as much. “Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on,” said Snowden. In addition, Schneier said, “I believe this is true.” He continued to say, “Trust the math. Encryption is your friend. Use it well, and do your best to ensure that nothing can compromise it. That’s how you can remain secure even in the face of the NSA.” However, the media seems to be spinning things as if encryption is broken in its entirety. If it is not, then the question remains, what is broken?

Long Live the King

It is to our best understanding that 1024bit RSA must be retired. It is most likely able to be cracked in a much smaller time frame than originally thought possible. There are multiple facts that we’ve observed that led us to this conclusion, with the following quote seemingly confirming our suspicions: “Another program, codenamed Cheesy Name, was aimed at singling out encryption keys, known as ‘certificates’, that might be vulnerable to being cracked by GCHQ supercomputers.” This is indicative of the fact that only certain types of certificates are crackable, and the most likely culprit for that is the weak 1024bit RSA certificate which is still commonly used by many websites. If this is true, then it has huge implications for HTTPS traffic, but has minimal impact on OpenVPN traffic. Due to the fact that most web servers do not use an ephemeral key exchange, the vast majority of HTTPS traffic is decryptable by obtaining or cracking the RSA certificate’s private key.

3 Ghosts of Surveillance

Ephemeral key exchanges differ greatly from that of the non ephemeral key exchanges due to the fact that they do not rely, in any way, on certificates for the exchange of their secret keys. In other words, if a criminal is spying on your encrypted connection, even if the criminal were to somehow obtain the private key of the certificate, he or she would not be able to decrypt the transmission. In contrast, a non ephemeral key exchange relies solely on the secrecy of the certificate’s private key in order to maintain exchange secrecy. As such, in this case, once a private key is compromised, then all past, present and future non ephemeral exchanges will be compromised, just by watching them.

The silver lining to this is that if all web traffic simply upgrades to using ephemeral key exchanges, then the fact that 1024bit RSA encryption is broken will not have any effect as to whether dragnet decryption of HTTPS traffic can or will occur. Unfortunately, this is not the case in our contemporary internet, and as such, we have to assume the NSA is performing dragnet decryption of non ephemeral 1024bit RSA HTTPS connections, which makes up most of the web/HTTPS traffic on the internet.


Fortunately, the open source OpenVPN was designed to use ephemeral key exchanges in order to prevent any kind of mass dragnet decryption. This still leaves OpenVPN connections open to targeted man in the middle attacks assuming they have cracked the private key. We have put in motion several changes that will harden our service and, thus, prevent these new, powerful attacks from occurring.

Kryptonite is not the only weakness

There is yet another less-likely scenario as to what could be broken. It is possible that the 1024bit Diffie Helman key exchange protocol can be cracked in a reasonable amount of time. No one has mentioned anything about this and therefore we believe it unlikely to be the case. However, this would potentially allow the NSA to decrypt past or future OpenVPN or HTTPS sessions (using a 1024bit key exchange) that they may have passively recorded. Although this is most likely not the case, we at Private Internet Access have already upgraded all of our Diffie Helman key exchanges to 2048bit to ensure that this is not even a realistic possibility.

National Security Agency

According to The Guardian, ”Documents show that Edgehill’s initial aim was to decode the encrypted traffic certified by three major (unnamed) internet companies and 30 types of Virtual Private Network (VPN) – used by businesses to provide secure remote access to their systems. By 2015, GCHQ hoped to have cracked the codes used by 15 major internet companies, and 300 VPNs.”

This statement was, at first, alarming. However, after we analyzed all of the reports thoroughly as well as consulted subject matter experts both in-house and externally, we are in belief that they are referring to different types or implementations of PPTP VPN solutions including hardware, software, or even open source PPTP implementations. After all, PPTP has historically used many cryptographic algorithms that were subsequently proven to be broken or weakened to the point of uselessness. In addition, it’s also an extremely aged/legacy protocol, so there are most likely many different variants included in commercial offerings. We believe the NSA is merely referring to attempts to set up their systems to automatically detect and decrypt all of the different PPTP variants. This would, of course, enable them to obtain traffic from many large organizations, institutions, and even some governments that still use these expensive legacy commercial systems.

A second, less likely (update: this is seeming much more likely than we originally estimated), possibility is that they are referring to cracking commercial IPSec VPN offerings. This is probably not the case, because IPSec is a much more secure protocol which uses the same building blocks as TLS. With that said, there are still many possibilities where the NSA could have either found or coerced weaknesses into commercial hardware IPSec offerings. For example, this could include something similar to the HTTPS issue where non ephemeral key exchanges are used, using weak or broken cryptographic primitives, random number generator weaknesses where the NSA can predict the random numbers, or flaws in the IPSec implementation which could leak secret information.

A third possibility is that they are referring to network routing technologies which are sometimes referred to as VPNs and may or may not even be encrypted, such as MPLS.

We do not believe that they are referring to OpenVPN in any way, shape or form at this time based on the statements that have been made. OpenVPN relies on the same cryptographic building blocks as TLS, is built as an open source project, always uses ephemeral key exchanges, and finally, must be interoperable with all other OpenVPN protocol/versions. These 4 facts make it extremely unlikely that there is some fatal flaw in OpenVPN which makes it subjectable to decryption in a dragnet fashion by the NSA. Even Schneier agrees when he states, “Try to use public-domain encryption that has to be compatible with other implementations.”

Private Internet Access has got your back

As stated above, we have already increased our key exchange security to 2048bit preventing any sort of unknown NSA cracking ability. In addition, within a few weeks, we will be releasing a new client that will allow people to select how much security they want, both for the certificate and the key exchange, as well as the symmetric cipher security. Our default certificate will be 2048bit, but we will allow users to choose both 3072bit and 4096bit if they want to be especially cautious. We will also be adding support for something no other provider is currently offering called Elliptic Curve Cryptographic security, with both 256bit and 521bit curves. This is cutting edge cryptography that we want to make available to our users who choose to use it.


coderrr has been involved with network and computer related security for over a decade. Foreseeing how important security and privacy would become, coderrr co-founded Private Internet Access. In addition, he co founded Mt. Gox Live, and previously, worked with high frequency Forex and online poker. coderrr also worked on some early privacy extensions to Bitcoin.