Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support processing of very large payloads in RAMF messages #14

Open
gnarea opened this issue Jul 7, 2019 · 0 comments

Comments

@gnarea
Copy link
Member

@gnarea gnarea commented Jul 7, 2019

The CMS EnvelopedData structure used to serialise the RAMF payload contains the ciphertext, which makes it really difficult to encrypt or decrypt the payload is a stream-based manner (i.e., without holding the whole plaintext and ciphertext in memory).

This shouldn't be a problem with parcels, because each parcel shouldn't be more than a few megabytes (its encapsulated service message is typically meant to be held in RAM anyway). However, cargoes may contain a large number of parcels, which collectively could be too big to be held in memory during encryption or decryption.

Proposed changes to the RAMF spec

  1. Detach the ciphertext (encryptedContentInfo.encryptedContent) from the CMS EnvelopedData value.

  2. Place the CMS EnvelopedData value before the ciphertext so the symmetric key can be available before reading the ciphertext.

  3. Reinstate the signature hashing algorithm as a RAMF message field so that a consumer can start computing the digest as the message is being received:

    The algorithm MUST be valid per RS-018. This value MUST be DER-encoded as an ASN.1 Object Identifier; for example, SHA-256 (OID 2.16.840.1.101.3.4.2.1) would be encoded as 06 09 60 86 48 01 65 03 04 02 01. It MUST also have a fixed length of 16 octets, right padded with 0x00.

    This will involve partially reverting d3bc4fa

We should also consider the implications of supporting large payloads when producing and verifying the digital signature. Algorithms like Ed25519/Ed448 can't work with streams, so we'll have to use their pre-hash variant instead.

Why this isn't supported from day 1

Because PKI.js (used by relaynet-core-js) doesn't support stream-based plaintexts (see: PeculiarVentures/PKI.js#237). Bouncy Castle (to be used by relaynet-core-java) does support streams.

gnarea added a commit that referenced this issue Jul 7, 2019
@gnarea gnarea changed the title Support large payloads in RAMF messages Support encryption and decryption of very large payloads in RAMF messages Jul 7, 2019
@gnarea gnarea changed the title Support encryption and decryption of very large payloads in RAMF messages Support processing of very large payloads in RAMF messages Jul 11, 2019
gnarea added a commit that referenced this issue Jul 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.