Giter VIP home page Giter VIP logo

crypt-rfc8188's Introduction

NAME

Crypt::RFC8188 - Implement RFC 8188 HTTP Encrypted Content Encoding

PROJECT STATUS

OS Build status
Linux Build Status

CPAN version Coverage Status

SYNOPSIS

use Crypt::RFC8188 qw(ece_encrypt_aes128gcm ece_decrypt_aes128gcm);
my $ciphertext = ece_encrypt_aes128gcm(
  $plaintext, $salt, $key, $private_key, $dh, $auth_secret, $keyid, $rs,
);
my $plaintext = ece_decrypt_aes128gcm(
  # no salt, keyid, rs as encoded in header
  $ciphertext, $key, $private_key, $dh, $auth_secret,
);

DESCRIPTION

This module implements RFC 8188, the HTTP Encrypted Content Encoding standard. Among other things, this is used by Web Push (RFC 8291).

It implements only the aes128gcm (Advanced Encryption Standard 128-bit Galois/Counter Mode) encryption, not the previous draft standards envisaged for Web Push. It implements neither aesgcm nor aesgcm128.

FUNCTIONS

Exportable (not by default) functions:

ece_encrypt_aes128gcm

Arguments:

$plaintext

The plain text.

$salt

A randomly-generated 16-octet sequence. If not provided, one will be generated. This is still useful as the salt is included in the ciphertext.

$key

A secret key to be exchanged by other means.

$private_key

The private key of a Crypt::PK::ECC Prime 256 ECDSA key.

$dh

If the private key above is provided, this is the recipient's public key of an Prime 256 ECDSA key.

$auth_secret

An authentication secret.

$keyid

If provided, the ID of a key to be looked up by other means.

$rs

The record size for encrypted blocks. Must be at least 18, which would be very inefficient as the overhead is 17 bytes. Defaults to 4096.

ece_decrypt_aes128gcm

$ciphertext

The plain text.

$key

$private_key

$dh

$auth_secret

All as above. $salt, $keyid, $rs are not given since they are encoded in the ciphertext.

SEE ALSO

https://github.com/web-push-libs/encrypted-content-encoding

RFC 8188 - Encrypted Content-Encoding for HTTP (using aes128gcm).

AUTHOR

Ed J, <etj at cpan.org>

LICENSE

Copyright (C) Ed J

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

crypt-rfc8188's People

Contributors

mohawk2 avatar

Watchers

 avatar  avatar

crypt-rfc8188's Issues

Tiny improvements

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!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.