RFC 5054 paddings

[amitkriit]

RFC 5054 specifies left padding during calculation of k and u as expressed below:
k = H(N, PAD(g))
u = H(PAD(A), PAD(B))

PAD(X) inserts left padding (zeros) into the binary big-endian representation of X to match it's number of bytes with the number of bytes in N.

Current code doesn't compute the paddings.

[cocagne]

You're correct about that. CSRP was written before RFC5054 became the de-facto standard for inter-implementation padding should be implemented and, unfortunately, changing the default implementation would break existing applications that are already dependent on the current hashing approach. That said, there is an rfc5054_compat branch of csrp that implements rfc5054 and is known to be compatible with other libraries. It should be relatively straight-forward to modify the default csrp implementation to default to the current hashing approach but be easily converted to rfc5054 compliance via a a command-line argument but doing so hasn't yet been a high enough priority for someone to submit a patch for it. I've received several notes similar to yours though so I think it's time to update the readme to explicitly call this out and point people over to the rfc5054_compat branch.

…

On Sat, Feb 10, 2018 at 9:18 AM, amitkriit ***@***.***> wrote: RFC 5054 specifies left padding during calculation of *k* and *u* as expressed below: k = H(N, PAD(g)) u = H(PAD(A), PAD(B)) PAD(X) inserts left padding (zeros) into the binary big-endian representation of X to match it's number of bytes with the number of bytes in N. Current code doesn't compute the paddings. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABrLfBAg74CfCAdJx4nOZbz91ngzERMaks5tTbM5gaJpZM4SA9hp> .