Bug 12634

Summary: Ed25519 incorrectly listed as stronger then actual
Product: IPFire Reporter: Ian - <ian>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: CLOSED FIXED QA Contact:
Severity: Security    
Priority: - Unknown - CC: peter.mueller, peter.mueller
Version: 2   
Hardware: x86_64   
OS: Unspecified   
Attachments: screenshot
Transposition

Description Ian - 2021-06-13 19:39:57 UTC 
Created attachment 906 [details]
screenshot

In the cipher sections for IPSec and OpenVPN, Ed25519 is at the top and listed as 256 bit security.

This is not correct, see https://crypto.stackexchange.com/questions/67457/elliptic-curve-ed25519-vs-ed448-differences

and

https://github.com/RubyCrypto/ed25519/blob/master/README.md#:~:text=Ed25519%20provides%20a%20128%2Dbit,256%2C%20and%20RSA%2D3072.&text=Small%20signatures%3A%20Ed25519%20signatures%20are,the%20smallest%20signature%20sizes%20available.

"Ed25519 provides a 128-bit security level, that is to say, all known attacks take at least 2^128 operations, providing the same security level as AES-128, NIST P-256, and RSA-3072"

Ed448 provides 224 bit equivalent security and Ed25519 provides 128 bit equivalent security.

Really I think that Ed448 should be on top of the list and Ed25519 under it, and labeled as 128 bit instead of 256 bit.
Comment 1 Michael Tremer 2021-06-14 09:32:07 UTC 
Hey Ian,

thank you for this bug report. You are correct, the order is probably misleading.

I changed it and I will push a patch shortly. However, strongSwan prefers Curve25519 over Curve448. That is probably how we ended up with the same sorting because I ranked the algorithms similar to what is on their website: https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites

In general it is a bit difficult to order them correctly. There are lots of factors involved, but I suppose the complexity as you proposed is a good indicator which should help people to make the right choice. Who ends up on the "advanced settings" page hopefully knows a thing or two about what they are doing.
Comment 3 Ian - 2021-06-14 10:22:55 UTC 
Created attachment 907 [details]
Transposition

Image of transposition error
Comment 4 Ian - 2021-06-14 10:24:21 UTC 
(In reply to Michael Tremer from comment #2)
> > https://patchwork.ipfire.org/project/ipfire/patch/20210614093346.11267-1-michael.tremer@ipfire.org/
> 
> Please review.

Hi Michael looking at the diff it looks good with the exception of one transposition error (See attached picture) where one line has clobbered 25519 and has 448 twice instead. Other than that, from the diff, looks good to me.

Cheers
Comment 5 Ian - 2021-06-14 10:25:10 UTC 
Sorry I am not used to this bugzilla thing so my picture was posted seperate from post
Comment 6 Michael Tremer 2021-06-14 13:31:06 UTC 
(In reply to Ian - from comment #4)
> (In reply to Michael Tremer from comment #2)
> > > https://patchwork.ipfire.org/project/ipfire/patch/20210614093346.11267-1-michael.tremer@ipfire.org/
> > 
> > Please review.
> 
> Hi Michael looking at the diff it looks good with the exception of one
> transposition error (See attached picture) where one line has clobbered
> 25519 and has 448 twice instead. Other than that, from the diff, looks good
> to me.

Thanks for reviewing this. Good catch.

I posted a fixed version of this patch (https://patchwork.ipfire.org/project/ipfire/patch/20210614132828.409-1-michael.tremer@ipfire.org/) and merged it into next for release with Core Update 158.