mohawk2 / crypt-rfc8188 Goto Github PK

Hi.

Thank you for implementing this RFC. There are few things that I think can be improved, feel free to take from my review what you think is reasonable:

Useless use:

use MIME::Base64 qw(encode_base64url decode_base64url); # not used at all
use Crypt::KeyDerivation qw(hkdf hkdf_extract hkdf_expand); # extract / expand are not used at all

Byte contexts:

Perl is messy, there is no separate Buf type for binary buffers (like in Raku) and length behavior depends on internal encoding. Also Perl 7 will give more sane defaults and it will steer towards utf-8 handling by default. I think the safest way to avoid utf-8 encoded bytes slipping in is to:

• encode user $salt (or die if utf flag is detected), same for $content
• use explicit bytes::length instead of length in the whole module
• explicitly pack everything binary: pack( 'a*', "WebPush: info\0" ) . $receiver_pub_key . $sender_pub_key, especially if it is concatenated with other strings.
  (i know current version works, but explicit byte contexts will be more bomb-proof)

Padding:

Padding simplification - your code (if I'm reading it correctly) does no padding at all during encoding. It only adds \x02 padding separator. I think you can solve padding-only last block issue more easily, just by adding \x02\x00\x00\x00... so that total length will never align with block size. Easy to calculate up-front.

When decoding padding removal regexp should be $data =~ s/\x00*\z//;, difference is:

perl -E '$encoded = "abc\x02\x00\n"; say unpack("H*", $encoded =~ s/\x00*$//r); say unpack("H*", $encoded =~ s/\x00*\z//r);'

616263020a
61626302000a

Yes, version with $ in regexp wlll die in the next few lines anyway if someone by accident provides newline ended payload. But to be very strict - replacement should not modify things it was not intended to match in the first place.

Interface:

It's not exactly clear from documentation how to provide keys. Should they be Crypt::PK::ECC instances or raw uncompressed bytes. IMO the less user deals with binary data the happier the place world is :) Or maybe accept both and if user provides Crypt::PK::ECC instance do ->export_key_raw('TYPE_uncompressed') internally?

Accepting Crypt::PK::ECC instances will have a lot of sense in WebPush scenario, where subscription keys do not change between messages to the same user and there is no point in rebuilding ECC instance with every push sent.

Thanks!