Open piem opened 6 years ago
@freimair What is your feedback to that?
Even if we want to change the keys that would be difficult to deploy as it would break compatibility with not upgraded nodes. If we would change, ECDSA might be a better alternative anyway. We want to keep data size small for network objects.
I second that. If we can, we should upgrade to ECDSA.
I will think about a solution to the compatibility issues. Also, I will review the code in terms of duplication and overall soundness as I did my share of crypto coding. That is, if you, Manfred, agree.
@freimair Sure! Any improvement is welcome!
Re compatibility: I fear there will be no easy ways as old clients would not accept messages if the signature check fails. So even if new clients would support both to support old clients, the old clients will cause the problem. Not sure if there is a solution for that beside either a hardfork which we want to avoid if not absolutely necessary or to be a bit intolerant to very old version and add the new version, keep it inactive until a certain activation data and then old clients who have not updated will get forced to do that. That might be doable but not sure if the issue is critical enough to use such a strategy. The threat model for the sig check is likely not requiring top security. The sig check guarantees that an offer for instance cannot be removed by another node but only by the owner. But is there any incentive beside sabotage to do that? Breaking the 1024 key is also not easy and cheap. So I have the feeling that this issue is not worth extra effort. We can though update it for the next hardfork - once every 2 years a hard fork is ok to clean up stuff if required. So far there is not anything urgent so no idea when that will be...
DSA 1024 should be considered harmful nowadays.
in
src/main/java/bisq/common/crypto/Sig.java
, line 64:Additionally, some code duplication could be avoided (
generateKeyPair
is defined at least twice inSig.java
andEncryption.java
).