Secure Network FAQ

Q:	What encryption is used in your OpenVPN tunnel?
A:	Anonymator OpenVPN tunnel uses a strong encryption technology, specifically 256-bit AES and 2048-bit public key algoritms.

What is AES?

AES stands for Advanced Encryption Standard. AES is a symmetric key encryption technique which will replace the commonly used Data Encryption Standard (DES).
It was the result of a worldwide call for submissions of encryption algorithms issued by the US Government's National Institute of Standards and Technology (NIST) in 1997 and completed in 2000.
The winning algorithm, Rijndael, was developed by two Belgian cryptologists, Vincent Rijmen and Joan Daemen.
AES has achieved acceptance and adoption from both governments and private enterprises. The National Security Agency (NSA) reviewed all the AES finalists, including Rijndael, and stated that all of them were secure enough for U.S. Government non-classified data. In June 2003, the U.S. Government announced that AES could be used for classified information. In May of 2005, Microsoft announced that it had added a wireless LAN security specification to Windows XP. The specification, called Wi-Fi Protected Access 2 (WPA2), requires a Wi-Fi client to include the AES algorithm for encrypting data traversing a Wi-Fi network. Because of its efficiency and power, AES will be with us for the long haul.

What is RSA?

RSA is a public-key cryptosystem defined by Rivest, Shamir, and Adleman.
It is based on the assumption that it is easy to multiply two prime numbers, but difficult to divide the result again into the two prime numbers. To create her public/private key pair, and to encrypt and decrypt messages, Alice now must do some complicated calculations.
Because the RSA system is rather slow, it is most often used to encrypt a so-called "session key". This session key in turn is used to encrypt the actual message with a (fast) secret key encryption system.
The security of the RSA cryptosystem is based on two mathematical problems: the problem of factoring large numbers and the RSA problem. Full decryption of an RSA ciphertext is thought to be infeasible on the assumption that both of these problems are hard, i.e., no efficient algorithm exists for solving them.

Can AES be brute-forced?

In the late 1990s, specialized 'DES Cracker' machines were built that could recover a DES key after a few hours. In other words, by trying possible key values, the hardware could determine which key was used to encrypt a message.
Assuming that one could build a machine that could recover a DES key in a second (i.e., try 2⁵⁵ keys per second), then it would take that machine approximately 149 thousand-billion (149 trillion) years to crack a 128-bit AES key. To put that into perspective, the universe is believed to be less than 20 billion years old.

Can RSA be brute-forced?

The security of the RSA cryptosystem is based on mathematical problem of factoring large numbers.
Still, factoring large numbers is hard. However, with the advances in number theory and computing power, it is getting easier. In 1977 Ron Rivest said that factoring a 125-digit number would take 40 quadrillion years. In 1994 RSA129 was factored using about 5000 MIPS-years of effort from idle CPU cycles on computers across the Internet for eight months. In 1995 the Blacknet key (116 digits) was factored using about 400 MIPS-years of effort (1 MIPS-year is a 1,000,000 instruction per second computer running for one year) from several dozen workstations and a MasPar for about three months. Given current trends the keysize that can be factored will only increase as time goes on.
The table below estimates the effort required to factor some common PGP-based RSA public-key modulous lengths using the General Number Field Sieve:

Key size	MIPS-years required to factor
512	30,000
768	200,000,000
1024	300,000,000,000
2048	300,000,000,000,000,000,000

What is the principle behind OpenVPN tunnels?

Okay, here is a brief summary of the principle behind OpenVPN:
Imagine you had a direct physical wire (i.e. a long cable) connecting two computers (A and B) at different locations. On each computer there would be a /dev/longcable which would be a network device. You could route IP traffic over it, and do everything you could normally do with a network device.
Basically a tun device is like having a /dev/longcable except the OpenVPN daemon is the program that connects the /dev/longcable on computer A with the /dev/longcable on computer B so that you can use the internet rather than a real physical cable. But in this case it is called /dev/tun or whatever your OS prefers to call them.
Now the mechanism by which OpenVPN connects /dev/tun on computer A with /dev/tun on computer B is this: It simply creates an encrypted UDP connection over the internet between A and B and forwards traffic between /dev/tun on A with /dev/tun on B. Because of the clever way in which the tun and tap drivers were designed, it is possible for a program running entirely in user-space to effect this link, allowing OpenVPN to be a portable cross-platform daemon (like SSH), rather than an OS-specific kernel module (like IPSec).
The difference between a tun and tap device is this: a tun device is a virtual IP point-to-point device and a tap device is a virtual ethernet device. So getting back to the "long cable" analogy, using a tun device would be like having a T1 cable connecting the computers and using a tap device would be like having an ethernet network connecting the two computers. People who are running applications that need the special features of ethernet (which won't work on an IP-only network) will often bridge their physical local ethernet with a tap device (using a utility such as brctl on Linux), then VPN the tap device to another similar setup at the other end. This allows OpenVPN to route ethernet broadcasts and non-IP protocols such as Windows NetBios over the VPN. If you don't need the special features of ethernet (such as bridging capability), it's better to use a tun device.
Tun and tap devices can be interconnected to create a complex routing topology. Some people have created multi-node WAN networks over tap devices and actually run DHCP over the VPN so that clients can log into the virtual ethernet and request an IP address. I've even heard of people using Linux advanced routing to run OSPF (a kind of dynamic routing protocol) over the VPN WAN to allow for dynamic, fault-tolerant routing. They sky is the limit as far as the complexity of network you can build, but the basic building block is a VPN daemon such as OpenVPN connecting tun or tap devices on two different machines.

Are there any known security vulnerabilities with OpenVPN?

Not to our knowledge (as of 2004.12.08). The current OpenVPN security model matured by version 1.1.0, which was released in 4/2002. Since that time, there have been no confirmed reports on the OpenVPN lists or other security-related forums claiming any security vulnerabilities due to bugs in the software.
Having said that, there is always the potential for security vulnerabilities to be introduced by incorrect configurations. One such vulnerability is discussed here.
While OpenVPN has not as yet been subjected to a comprehensive security review, so far the security model has stood up well to analysis. In 9/2003, cryptography expert Peter Gutmann looked at the field of open source VPNs with a critical eye, and OpenVPN was singled out for some positive remarks.
OpenVPN's security model can be summarized as such: Use the IPSec ESP protocol for tunnel packet security, but then drop IKE in favor of SSL/TLS for session authentication. This allows for a lightweight, portable VPN implementation that draws on IPSec's strengths, without introducing the complexity of IKE.
See the article OpenVPN and the SSL VPN Revolution (PDF), by Charlie Hosner, for a more in-depth look at OpenVPN from a security perspective.
While it's impossible to assure with certainty that no weaknesses exist, OpenVPN has multiple levels of security to protect against a single flaw causing a catastrophic security breach. For example, by using --user nobody --group nobody you can ensure that even if some kind of remote buffer overflow exploit were discovered, the exploit would be unable to elevate its privilege to root. Another example is using SSL/TLS security with --tls-auth. Using --tls-auth ensures that even if a remote buffer overflow is discovered and exploited in the SSL/TLS authentication code in the OpenSSL library, it could not be used to attack an OpenVPN session that is protected with a --tls-auth password. In addition, if you use SSL/TLS authentication, you have the benefit of "perfect forward secrecy".

General FAQ

Support FAQ

Secure Network FAQ