Re: [GNUnet-developers] EcDSA signature scheme

[hyazinthe]

*Disclaimer: I'm not skillful in cryptography. I hope you can tolerate random 
input with intention to help GNUnet crypto in general. I hope that the input is 
helpful in any case and sorry if the input is not helpful in any case. More 
eyes see more. Sometimes also including the unskillful ones.*

When it comes to double application/hashing after the 1st round of it one 
should do "Xor" or in other words 'push down a bit/swap a bit/change a bit'

Nonce always have to be different and in being so unique - without any 
exception.

What crypto in general to use:
1. MRAE - (nonce)-misuse-resistant-authenticated-encryption:
Especially RIV - Robust Initialization Vector - 
https://www.researchgate.net/publication/305421597_RIV_for_Robust_Authenticated_Encryption
otherwise SIV - Synthetic Initialization Vector
But the downside of it is that it's slow/effortful, because it has to go over 
cleat text for 2 times
So, this crypto is not suitable for realtime applications/streaming
But it's the most secure crypto.
2. Robust authenticated encryption:
If one is dealing with realtime applications/streaming, one should go down one 
step
from MRAE to this Robust authenticated encryption.
Especially POET is a good choice, that's the successor generation of McOE-G.
Otherwise McOE-G or maybe COLM is a good pick.
That's the 2nd most secure crypto.

But in times of quantum computers - by 2018 NSA could have a decent one - it's 
probably better to increasingly consider Post-Quantum Cryptography (PQCrypto), 
because then ECDSA and ECDH are also no longer secure anymore.
I found this page to be useful for overview: 
https://www.whonix.org/wiki/PQCrypto .
For more details this page is very good: https://pqcrypto.org/
Did you know that the TOR project planned to migrate to quantum resistant 
ciphers by version 0.2.9.x ( 
https://trac.torproject.org/projects/tor/ticket/17286 + 
https://trac.torproject.org/projects/tor/ticket/24985 ) ? But my impression is, 
that they've done the fatal mistake to postpone this to a far, far, undefined 
point in the future.


Greetings,
Bastian Schmidt

--- Ursprüngliche Nachricht ---
Von: Bernd Fix <address@hidden>
Datum: 13.07.2018 11:26:44
An: address@hidden
Betreff: Re: [GNUnet-developers] EcDSA signature scheme

> I think that most problems mentioned in my previous post originate in
> the '#define CURVE "Ed25519"' statement at curve_ecc.c:37. All
> key
> parameter definitions (EdDSA, ECDSA and ECDHE) use that value leading to
>
> the described problems. I think that the curve key parameter needs to be
>
> set individually for each purpose.
>
> I have created a new branch "new_crypto" to collect the changes
> I see
> fit for the EC crypto stuff. I hope to be able to push it later today
> (if not, I will not be able to do so before next Wednesday).
>
> As more changes in crypto are pending (iirc it was mentioned that the
> timestamp will be removed from the HMAC computation), we could collect
> these changes in that new branch.
>
> Any suggestions or comments?
>
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>