Wishlist: Adding ciphers that are in other major libraries

[DonaldTsang]

The goal of this Issue is to "price match" libtomcrypt with other cryptographic libraries in regards to functionality and variety.

reference: https://www.cryptopp.com/

• Block Cipher

• IDEA
• Kalyna
• SIMON and SPECK
• SM4
• Threefish 256/512/1024
• Serpent
• SHACAL 1 and 2
• TEA

• Stream cipher

• Salsa20 and XSalsa20
• Panama
• Sosemanuk

reference: https://botan.randombit.net/manual/

• Block Cipher

• DESX
• GOST-28147-89
• Lion
• MISTY1
• Serpent
• SM4
• Threefish

• Stream Cipher

• Salsa20
• SHAKE128

• Block Cipher

• SIV

• Others

• Cipher Cascades

reference: http://www.bouncycastle.org/csharp/index.html

• CAST6
• DESede
• GOST28147
• HC-128 and HC-256
• ISAAC
• Serpent
• TEA/XTEA
• Threefish
• Tnepres
• VMPC
• XSalsa20
• GOFB mode
• OpenPGPCFB mode

Elliptic curves that are safe
reference: https://eprint.iacr.org/2013/647

Type	224-bit	256-bit	384-bit	512-bit
Montgomery	- [ ] M-221	- [ ] Curve25519	- [ ] M-383	- [ ] M-511
Edwards	- [ ] E-222	- [ ] Curve1174	- [ ] E-382	- [ ] E-512

[DonaldTsang]

I would like to note that Salsa20, XSalsa20 and ChaCha20 are all different ciphers.

[sjaeckel]

I would like to note that Salsa20, XSalsa20 and ChaCha20 are all different ciphers.

XSalsa20 is missing but the two others are already in the latest develop branch.

Btw. do you intend to submit PR's for all these ciphers? Or is this really just a wishlist ;)

[sjaeckel]

SIV can be ticked as soon as #319 is finished

[DonaldTsang]

@sjaeckel I have some basic C skills, really want to PR when I understand pointers and OO.
I might need some guidance on copy-pasting ciphers correctly to conform with coding standards.

[karel-m]

@DonaldTsang I think we should aim at features available in modern crypto libraries like libsodium which is IMO what "cool kids" tend to use nowadays. If you have some spare time, could you please analyse what we are missing in comparison to libsodium?

From your list I agree with XSalsa20 + SIV but the rest are rarely used and IMO mostly not worth the effort (but I might be wrong; if you show me some real use-cases I may change my mind).

[LightBit]

@karel-m Should Salsa20 be extended to XSalsa20 (when longer IV is used) or should it be separate implementation?

[sjaeckel]

@LightBit if Salsa20 can easily be turned into XSalsa20 at runtime, so both could use the same basis, I'm pro extension. Otherwise we'd have to have a look what's best.

[karel-m]

ping @buggywhip ^^

[LightBit]

@sjaeckel Due to salsa20_ivctr64(), extension would add 64 bytes overhead in state for Salsa20 to save key and IV. It would re-setup, if IV is different and longer than 8 bytes, else only counter would change.

[karel-m]

Due to salsa20_ivctr64(), extension would ...

As salsa20 was not released yet (it is only in develop branch) we can still change its API if needed - e.g. incorporating salsa20_ivctr64 into salsa20_setup or/and introducing salsa20_xsetup.

[sjaeckel]

As salsa20 was not released yet (it is only in develop branch) we can still change its API if needed

yep

e.g. incorporating salsa20_ivctr64 into salsa20_setup or/and introducing salsa20_xsetup.

whoever wants to add xsalsa20 should just do it (preferably based on our salsa20)
we'll then bring it in form together if required :)

[buggywhip]

whoever wants to add xsalsa20 should just do it (preferably based on our salsa20) we'll then bring it in form together if required :)

I'm willing to take this on but need to finish my current project. ...or at least get to a good stopping point. ...perhaps in a week or two?