Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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
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.