Zero-padding issue shouldn't be in v4
olabini opened this issue · comments
We should make sure this issue: https://github.com/jitsi/otr4j/issues/24 - is not in v4.
I think we might have this on the library.
So, in the spec is specified that:
(MPIs must use the minimum-length encoding; i.e. no leading 0x00 bytes.
This is important when calculating public key fingerprints)
Which is for the DH keys, as MPIs, as well. Now, in the actual implementation I think we are adding sometimes leading zeros (per a mem bug that was not fully solved).
Do you think this is enough? @olabini
Where in the implementation? And are you talking about adding leading zeroes to the internal representation or to the external encoding?
as a related note, TLS < 1.3 used the "no 0x00 bytes for DH" rule, but since 1.3 they don't strip anymore 0x00 bytes - which I prefer (but obviously, do what you like - but please put it in the spec). :) thanks!
I was referring to something around these lines: otrv4/libotr-ng@6ec6ccf#diff-8412aa621cad7d8098b9f0fa638c3e27
@olabini
@hannesm : We have this on the MPI definition:
Multi-precision integers (MPI):
4 byte unsigned len, big-endian
len byte unsigned value, big-endian
(MPIs must use the minimum-length encoding; i.e. no leading 0x00 bytes.
This is important when calculating public key fingerprints)
In OTRv3 they don't have the leading 0x00 bytes for calculating the fingerprints. Do you think is clear enough with that definition?
@claucece thanks, that looks cleat enough to me.