REQUEST - CIPHERSUITE

[johnqpublic 1]

Please allow the use of SHA-256 or SHA-512 to go with AES-256 (the strength of a hash is half its output in bits due to birthday paradox, and I know HMAC use of hash is stronger than plain unkeyed digest) for a better match in security levels with an increased execution cost for servers and clients,

 

Or, please allow a AES-128 option, as 128 bits is more than secure enough (the margin of 256 bit AES over 128 is questionable at best due to the poor key scheduling and insufficient number of rounds, and it is /more/ susceptible to timing attacks), faster for both your hardware and my hardware to run, and is a better match to the 80-bit security level of your HMAC and the 112-bit security level of your RSA-2048 key exchange. Using rSA-2048, by definition anything over about 110 bits is complete overkill as the key is exchanged using the 'equivalent' of 112 bits of security: if you stick a 512 bit key in a RSA-2048 bit wrapper, recovering plaintext is just as easy as factoring RSA-2048 (approx. 2^112 work) to recover the plaintext key, rather than cracking the cipher itself.

 

 

I'd also like, as secondary suggestions, some ECC option (if only one, the Brainpool 512 bit curve; if a widely-used one, the Curve25519), or at least RSA-4096 (~160 bit strength).

 

But, please, let us either use at least RSA-2048-AES-128-SHA256 or (ECDHE or) RSA-4096AES-256-SHA2(256, 512) so the matches in security levels aren't so all over the place, and hardware expenditure isn't so great. You could save money on hardware accelerators, and I could save 50% of my crypto cycles or more even with AES-NI.

 

If you had to switch to one, and offer no options, RSA-4096 (if your hardware can do it quickly enough)-AES128-SHA256.

 

It sucks if you're reliant on hardware crypto accelerators or ASICs that are baked to do SHA-1 but can't do 256/512.

 

Thanks,

 

C//Ͻ

[Staff 9755]

Hello!

 

1) HMAC SHA384 is already available as authentication cipher in the Control Channel.

 

2) RSA keys size is already 4096 bit, as a well as DH ones.

 

3) There is no reason to switch from HMAC SHA as authentication cipher in the Data Channel, but we don't rule out a switch in the future.

 

4) There is currently no plan to switch from AES-256 to AES-128 either on the Data Channel or the Control Channel.

 

https://airvpn.org/specs

 

Kind regards

[me.moo@posteo.me 80]

Please allow the use of SHA-256 or SHA-512 to go with AES-256 (the strength of a hash is half its output in bits due to birthday paradox, and I know HMAC use of hash is stronger than plain unkeyed digest) for a better match in security levels with an increased execution cost for servers and clients, Or, please allow a AES-128 option, as 128 bits is more than secure enough (the margin of 256 bit AES over 128 is questionable at best due to the poor key scheduling and insufficient number of rounds, and it is /more/ susceptible to timing attacks), faster for both your hardware and my hardware to run, and is a better match to the 80-bit security level of your HMAC and the 112-bit security level of your RSA-2048 key exchange. Using rSA-2048, by definition anything over about 110 bits is complete overkill as the key is exchanged using the 'equivalent' of 112 bits of security: if you stick a 512 bit key in a RSA-2048 bit wrapper, recovering plaintext is just as easy as factoring RSA-2048 (approx. 2^112 work) to recover the plaintext key, rather than cracking the cipher itself. I'd also like, as secondary suggestions, some ECC option (if only one, the Brainpool 512 bit curve; if a widely-used one, the Curve25519), or at least RSA-4096 (~160 bit strength). But, please, let us either use at least RSA-2048-AES-128-SHA256 or (ECDHE or) RSA-4096AES-256-SHA2(256, 512) so the matches in security levels aren't so all over the place, and hardware expenditure isn't so great. You could save money on hardware accelerators, and I could save 50% of my crypto cycles or more even with AES-NI. If you had to switch to one, and offer no options, RSA-4096 (if your hardware can do it quickly enough)-AES128-SHA256. It sucks if you're reliant on hardware crypto accelerators or ASICs that are baked to do SHA-1 but can't do 256/512. Thanks, C//Ͻ

 

Do you honestly believe the guys do not know their stuff or are you just out to show off?