Ξ 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

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

Topic Author
Posts: 49
Joined: Wed Jan 16, 2013 6:22 pm

PrivateInternetAccess.com: crypto confusion & snake oil

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

{direct link: pia.cryptostorm.org}

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.


User avatar

Topic Author
Posts: 49
Joined: Wed Jan 16, 2013 6:22 pm

Re: PIA: crypto snake oil | comment

Postby 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...


User avatar

Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am

1024 RSA declared "dead"... in 2007

Postby 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……… ҉҉҉

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


Re: PrivateInternetAccess.com: crypto confusion & snake oil

Postby 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: PrivateInternetAccess.com: crypto confusion & snake oil

Postby 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!

Return to “#cleanVPN ∴ encouraging transparency & clean code in network privacy service”

Who is online

Users browsing this forum: No registered users and 10 guests