# How NSA-proof are VPN Providers? – A response to criticism

As the author of the BestVPN article ‘How NSA-proof are VPN Providers? – We consider TorrentFreak’s article’, it has just come to my attention that a highly critical (and very rude) response was posted on the VikingVPN blog, claiming that my article ‘contains errors and inaccuracies.’ I in turn feel this response blatantly misrepresents my article’s contents , and that recent events have vindicated my suspicions about NIST certification.

This then, is a considered response to the VikingVPN article.

1. ‘**They lead off with criticism of iPredators selection of “OpenSSL with ECDHE + AES and without RC4” stating that OpenVPN is better.’**

What I actually said was,

‘That iPredator diverges from this consensus [on using OpenVPN], advocating ‘OpenSSL with ECDHE + AES and without RC4’ instead is interesting, but the fact that the company was using PPTP as its sole protocol as late as 2009 somewhat undermines its authority on the subject for us.’

I did not dismiss OpenSSL with ECDHE + AES and without RC4 on technical grounds, but simply cast doubt on the integrity/technical competence of its proponent. I will also note that I am fully aware that most instances of OpenVPN use the OpenSSL library.

2. ‘**They then go on to criticize RSA and AES in particular… **RSA is a math algorithm. People have been trying to solve simplifications to this problem since it was invented. There are no known simplifications beyond trying to brute-force it. The NSA had nothing to do with the math behind RSA.’

The NSA had nothing to do with developing the math behind RSA and AES, but given that NIST’s credibility has been seriously tarnished by its involvement with the NSA, and the fact that it certified the deliberately NSA weakened Dual_EC_DRBG algorithm, I feel a healthy skepticism over NIST certified standards is in order.

‘*NIST took a big credibility hit unfortunately. There are good people there doing good work but we don’t know which of their standards are tainted, we don’t know how much collaboration there is with the NSA. And unfortunately because trust is lost when they get up and say the NSA doesn’t affect our standards we don’t believe them. We need a way to get back trust.*’ Bruce Schneier, internationally respected security and cryptography expert.

Indeed now that the NSA’s campaign to undermine all encryption standards has become public knowledge courtesy of Edward Snowden, resulting in widespread distrust of NIST due to its close working relationship with the NSA, NIST has ordered a full review of ‘our existing body of cryptographic work, looking at both our documented process and the specific procedures used to develop each of these standards and guidelines.’

As to *how* a mathematical algorithm can be subverted, even when developed independently of NIST or the NSA,

‘*In the wake of Bruce Schneier’s statements that he no longer trusts the constants selected for elliptic curve cryptography, people have started trying to reproduce the process that led to those constants being selected … and found it cannot be done. As background, the most basic standard elliptic curves used for digital signatures and other cryptography are called the SEC random curves (SEC is ‘Standards for Efficient Cryptography’), a good example being secp256r1. The random numbers in these curve parameters were supposed to be selected via a “verifiably random” process (output of SHA1 on some seed), which is a reasonable way to obtain a nothing up my sleeve number if the input to the hash function is trustworthy, like a small counter or the digits of PI. Unfortunately it turns out the actual inputs used were opaque 256 bit numbers, chosen ad-hoc with no justifications provided. Worse, the curve parameters for SEC were generated by head of elliptic curve research at the NSA — opening the possibility that they were found via a brute force search for a publicly unknown class of weak curves. Although no attack against the selected values are currently known, it’s common practice to never use unexplainable magic numbers in cryptography standards, especially when those numbers are being chosen by intelligence agencies. Now that the world received strong confirmation that the much more obscure and less widely used standard Dual_EC_DRBG was in fact an NSA undercover operation, NIST re-opened the confirmed-bad standards for public comment. Unless NIST/the NSA can explain why the random curve seed values are trustworthy, it might be time to re-evaluate all NIST based elliptic curve crypto in general.’ *Source plus interesting discussion*, *and see also* *this paper.

Note that this also has implications for Elliptic curve Diffie–Hellman (ECDH) protocol discussed earlier. Furthermore, RSA is not, as such, that difficult to crack,

*‘A 1024 bit RSA key can trivially be cracked in 2^512 operations. An algorithm that uses 2^341 operations (cube root) and involves no more than high school maths was found about 1975. Then we need to go into deep maths, but there are algorithms that are significantly faster, and there is no good reason to think that more progress couldn’t be made. 128 vs 3072 is a bit much, but factoring 1024 bit numbers in 2^128 operations doesn’t seem impossible.’ *Source.

Of course, increasing the key size to 2048-bits, or even 4096-bits, will help protect against such a brute force attack.

It should also be observed that, as the recent catastrophic Heatbleed Bug debacle illustrates, the NSA throws huge resources at discovering weaknesses in cryptographic standards, and may therefore be aware of weaknesses in AES and RSA that others are not.

The fact that the Rijndael algorithm was chosen by NIST for its AES standard over Twofish (for example) based on practical implementation issues rather than cipher strength, means that it is not beyond the bounds of reason, given what we now know about the NSA, that the NSA pushed NIST to choose Rijndael because it might be an easier cipher to crack. That NIST’s published cryptanalysis of the five ciphers competing for AES selection appears to be incomplete and ‘insufficient’, provides further reason for suspicion.

3. ‘**They then recommend using the Skein Hash Function (also known as SHA3) over “RSA-1 and RSA-2’ **… Skein, (and the predecessors to it, SHA1 and SHA2) is for unidirectional encryption… These two things are completely different, and i’m hoping it is just an editing error and that the author meant SHA1 and SHA2, but i’m doubtful.

It was an editing error (as a freelance writer I edit my own work, and it is easy to mix-up RSA-1 with SHA1 ect. when knee-deep in research).

The Skein hash function was ‘one out of five finalists in the NIST hash function competition. Entered as a candidate to become the SHA-3 standard, the successor of SHA-1 and SHA-2, it ultimately lost to NIST hash candidate Keccak,’ (Wikipedia). VikingVPN was therefore entirely wrong to describe it as ‘also known as SHA3’ and therefore NIST certified (it isn’t).

For what it’s worth, I suggested the Skein hash function because it was the choice of Silent Circle CTO Jon Callas when he was discussing moving away from NIST certified encryption standards.

At present Skein, Twofish, Threefish or even SHA3 (Keccak)) are not part of OpenVPN, but there is no reason that they cannot be added.

### Conclusion

‘Please, as always, do not believe everything you read on the internet.’ Well, I believe the points made in my article stand, and that events since have only done more to further distrust at NSA meddling in the NIST certification process.

Despite the somewhat insulting tone of VikingVPN’s article, BestVPN has just published a broadly positive review of its service.