What encryption to use
-
hi Guys,
i've been watching alot of vpn tutorials on how to configure openvpn.
on each tutorial i've seen different encryption.
CF-CBS and AESA-128-CBC…
can you please advise which encryption is the most used in this matter.thank you
-
AES CBC or BF CBC
CBC is best for vpn as far as I know.
I am currently preferring BF.
-
I use AES because it's the strongest and it's quite fast on a modern x64+AES-NI CPU. About 330MB/s per core with OpenVPN, from what I've read. Plenty for even a 10Gb link, assuming not 100% VPN traffic with my quad core.
-
I will agree that its fast with hardware assistance, but it being strongest is up in the air.
I'd rather run something opensource thats never been broken than something made in collaboration with NSA and NIST thats never been broken.
If I REALLY REALLY din't care about those factors, I'd run Elliptic Curve for everything possible. Less overhead. Faster. Higher bandwidth.
I've been waiting for that to become the default standard.
But recently doubt has been cast on it. Something about suspicions of:
Cryptographic experts have also expressed concerns that the National Security Agency has inserted a backdoor into at least one elliptic curve-based pseudo random generator.[32] One analysis of the possible backdoor concluded that an adversary in possession of the algorithm's secret key could obtain encryption keys given only 32 bytes of ciphertext.
purposely injecting weak math…
The same guys who will tell you AES is safe forever, by the way.
-
ive been reading about AES-128 and AES-256
actually most of us think 256 is high number means more secure, but actually is not. the different is AESA-256 will take longer time to hack/crack than AES-128 beside both are the same.
in the mean while i am using AESA-256-CBC ( 256 bit ) with TLS + SSL+user auth
everything works great ! -
ive been reading about AES-128 and AES-256
actually most of us think 256 is high number means more secure, but actually is not. the different is AESA-256 will take longer time to hack/crack than AES-128 beside both are the same.
in the mean while i am using AESA-256-CBC ( 256 bit ) with TLS + SSL+user auth
everything works great !Both AES 128 and 256 have been "broken". Any symmetric encryption is considered "broken" if you can possibly break it faster than brute force. Brute force operations for a 256bit encryption is 2^256, AES-256 has a theoretical of about 2^254. AES 128 has a break time of about 2^126. AES-256 is about 10^38 times stronger than AES-128.
There are side channel attacks that can allow information about the key to be leaked, but these are not flaws inherent to AES, but flaws common to certain classes of encryption. It does mean that AES can be harder to use correctly, but many side channel attacks apply to many types of encryption, so it's best to know best practices.
AES is well vetted and well understood, relatively speaking. With current crypto theory and knowledge, if someone is telling you not to use AES, they're trying to sell you something, or possibly in a particular instance it is being used incorrectly, which has happened with HTTPS in the past few years as someone found a new side channel attack.
With the current strength of AES-256, one would need to covert the Sun's mass into pure energy and have a theoretically perfectly efficient computer to even have a chance at breaking a single key, assuming all operations can be completed in one cycle of an electron changing state and no energy is spent moving data around or storing data.
In reality, computers are not 100% efficient, there are multiple steps per operation and data must be transported around a computer. In practice, breaking a single AES-256 encrypted text would require the energy of all of the stars in the Milky way Galaxy. Until they find a good break that more than 2 bits, it's pretty safe.
-
I agree with Harvey. In a perfect world where no one has purposely designed the algorithm to be weak for them in some hard to detect way while being strong for everyone else, thus allowing them to crack at will secretly, then yes. AES seems like a great choice. Thing is the guys who selected this as the go-to standard work horse for encryption needs have a long established track record of weakening encryption covertly and foisting it on the world. Lets just say I don't trust them or anything they touch. Lets call it an irrational fear based completely in my own imagination. So, I use blowfish myself for now. If I hear of someone breaking it I will switch.
I will say this - Sooner or later (probably sooner) someone will break AES and Blowfish and they won't have to exhaust the sun to do it. This is always the case. Nothing is perfect.
-
My understanding is that BF is also impractical to break. Either are a good choice, I just prefer AES because of hardware acceleration and pipelines well on on x64 desktop cpus, but I hear BF does better on in-order cpus.
While I have high confidence in AES, I'm not going to judge because of what has been revealed in the past decade. What I've learned is a mono-culture is a bad thing. I wish we had more good options than just AES or BF.
edit: I've recently heard about Camellia. It's supposed to be similar in AES when it comes to performance and implementation. It is newer and less popular, so less understood, but it was created by some good names.
-
My understanding is that BF is also impractical to break. Either are a good choice, I just prefer AES because of hardware acceleration and pipelines well on on x64 desktop cpus, but I hear BF does better on in-order cpus.
While I have high confidence in AES, I'm not going to judge because of what has been revealed in the past decade. What I've learned is a mono-culture is a bad thing. I wish we had more good options than just AES or BF.
edit: I've recently heard about Camellia. It's supposed to be similar in AES when it comes to performance and implementation. It is newer and less popular, so less understood, but it was created by some good names.
I've been reading about Camellia too, seems a good too, its quiet old published on 2000, but less used so less popular and less understood ,
i have a big faith on AES, -
I did just find that there is a "related key" attack that could make AES192 and 256 much easier to break than 128, but still hard. A related key is where a group of keys share a lot of the same bits.
Here's a nice stackexchange description http://crypto.stackexchange.com/questions/1549/related-key-attacks-on-aes
Highlights
- the key owner will accept to process up to 2^99.5 blocks (that's 16-byte blocks, hence a grand total of about 14 thousands of billions of billions of gigabytes).
- The key owner can somehow be persuaded to compute three other keys
Attacker needs control of the keys and needs to get the target to process 12,738,103,345,051,545PiB of data, which would take 363,821,140,779,940 years with a 10Gb/s connection if it was a remote attack. But hey, 2^99.5 is a HUGE reduction from 2^254.
-
I will agree that its fast with hardware assistance, but it being strongest is up in the air.
I'd rather run something opensource thats never been broken than something made in collaboration with NSA and NIST thats never been broken.
So, let's get this straight. Are you suggesting that NSA and NIST conspired with a pair of Belgium cryptographers to include a weakness in an algorithm, then got it through a three year competition- as a favorite, I might add- during which the world's best academic cryptographers didn't find a problem. Or are you suggesting that NSA and NIST are miles ahead of the rest of the world at understanding block ciphers, and thus are able to break it while the rest of the world doesn't even have serious questions?
If I REALLY REALLY din't care about those factors, I'd run Elliptic Curve for everything possible. Less overhead. Faster. Higher bandwidth.
I've been waiting for that to become the default standard.
ECC isn't an alternative to AES, Blowfish, Camelia, etc. ECC is an alternative to public key algorithms- namely, RSA, Diffie-Hellman, and DSA (to be clear, the most popular ECC algorithms are really just variants of DH and DSA).
But recently doubt has been cast on it. Something about suspicions of:
Cryptographic experts have also expressed concerns that the National Security Agency has inserted a backdoor into at least one elliptic curve-based pseudo random generator.[32] One analysis of the possible backdoor concluded that an adversary in possession of the algorithm's secret key could obtain encryption keys given only 32 bytes of ciphertext.
purposely injecting weak math…
Apples and oranges. The random number generator referenced there, Dual_EC_DRBG, has nothing to do with the sort of elliptic curve cryptography used in things like OpenVPN (i.e., key agreement schemes).
The same guys who will tell you AES is safe forever, by the way.
Pretty much any cryptographer will tell you AES is safe, by the way.
AES is the best analyzed, best understood block cipher out there.
-
AES128 for me until something changes. Nothing against BF except lack of hardware acceleration.
-
I did just find that there is a "related key" attack that could make AES192 and 256 much easier to break than 128, but still hard. A related key is where a group of keys share a lot of the same bits.
Here's a nice stackexchange description http://crypto.stackexchange.com/questions/1549/related-key-attacks-on-aes
So, I know you didn't claim the AES attack is realistic, but I think its worth emphasizing that it shouldn't be a source of concern.
Related key attacks can be legitimate attacks- WEP is horribly insecure due to a related key attack- but the AES related key attack is wildly unrealistic. Part of that is due to the amount of work the victim has to do to be vulnerable to the attack, which you mentioned. The other part, which wasn't clear from your post, is that the attacker has to be able to get the victim to use three AES keys that are algorithmically related to the key being attacked. It's hard to even contrive a scenario where that could happen.
If you're looking for a serious, practical weakness in AES, it's side channels caused by vulnerable implementations. Notably, naive AES implementations could fall victim to a cache timing attack. What's the best way to avoid this vulnerability? Use crypto software that calls the AES-NI instructions in newer Intel processors. (Though, even without it, OpenSSL's other AES implementations should be reasonably safe.)
Even side channels attacks tend to require the victim to do a fair amount of work at the request of the attacker, which tends to result in fairly contrived attack models, but they are still far more troubling than the related key attack on AES-192/256.
-
Encryption is strong as it's weakest link is.
Symmetric encryption keys are transmitted over asymmetric encryption which depends on strength of the certificates. It doesn't help if your symetric encryption is top of the notch, if it's keys can be read.
Your certificates must use SHA-2 (at least SHA-256, preferred SHA-512) and at least 2048, preferred 3072 key length. -
Forward Secrecy is what you should be concerned with, not SHA1 or 2048-bit key pairs.
-
Forward Secrecy is what you should be concerned with, not SHA1 or 2048-bit key pairs.
By default DH is 2048, TLS is used, it should be enough for forward secrecy. Or I am wrong?
-
I always sort of giggle when people go through these big long examples of what is known about the strength of AES.
Its not what is known about AES that worries me. Its what we don't know.
I don't trust anything NSA likes or was involved in.
Their job has never been making things secure. Their job has ALWAYS been to make things insecure.
-
That is a reasonable position to take. I certainly trust Schneier more than the NSA, except Blowfish and AES were developed and submitted in the same "competition" if I understand correctly.
-
Correct and NSA didn't like blowfish…. haha
Thats my whole point.