*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 <[email protected]> Datum: 13.07.2018 11:26:44 An: [email protected] 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers > _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
