Skip to content

Enable use of the Padding packet in the API #435

Open
Open
Enable use of the Padding packet in the API#435
Assignees
hko-s

Description

@hko-s
hko-s
opened on Nov 21, 2024

RFC 9580 introduces a Padding packet.

Possible approaches I could imagine:

  • adding a padding parameter to a variant of Message::encrypt_symmetric_seipdv2 (that seems easy enough to do, but that API design feels maybe a bit too specific?)
  • adding a Message::add_padding_packet function to the Message type (that would probably be a non-trivial change on the implementation side)

... whichever API design we go for, we should make it easy for users to produce at least SEIPDv2 messages with padding in the internal payload.

Activity

  1. link2xt commented on Nov 21, 2024

    @link2xt
    link2xt
    on Nov 21, 2024
    Contributor

    RFC says it should be possible to pad transferable public key as well: https://www.rfc-editor.org/rfc/rfc9580.html#section-5.14

  2. link2xt commented on Nov 21, 2024

    @link2xt
    link2xt
    on Nov 21, 2024
    Contributor

    adding a Message::add_padding_packet function to the Message type (that would probably be a non-trivial change on the implementation side)

    Better this I guess, adding Message::Padded variant to Message enum and Message.pad API similar to Message.compress turning any Message into Message::Compressed

  3. hko-s commented on Nov 21, 2024

    @hko-s
    hko-s
    on Nov 21, 2024
    ContributorAuthor

    I am a bit worried about nudging users of the rPGP API to accidentally produce packet sequences that break interop with "legacy" implementation just because they can't handle padding packets.

    It seems safe to use Padding in SeipdV2 inner messages, and in v6 TPKs. In all other places it seems "too early" to me to encourage emitting Padding. But this is a delicate question in API design, and I'm open to being convinced that I'm too defensive 😅

  4. wiktor-k commented on Nov 21, 2024

    @wiktor-k
    wiktor-k
    on Nov 21, 2024
    Contributor

    Time to reuse... the Marker packet! 🫠

    Such a packet MUST be ignored when received.

  5. hko-s commented on Nov 21, 2024

    @hko-s
    hko-s
    on Nov 21, 2024
    ContributorAuthor

    Time to reuse... the Marker packet! 🫠

    It is tempting to consider using that packet, but it's not designed to produce padding of an arbitrary amount of bytes. Using it to get (almost) arbitrary byte amounts of padding would require silly hackery (e.g. mixing "old" and "new" style packet headers, and/or different length encodings).

    It's amusing to contemplate, but I'd be reluctant to use this approach 😃

  6. hko-s
    self-assigned this
    on Nov 21, 2024

  7. wiktor-k commented on Nov 22, 2024

    @wiktor-k
    wiktor-k
    on Nov 22, 2024
    Contributor

    Using it to get (almost) arbitrary byte amounts of padding would require silly hackery (e.g. mixing "old" and "new" style packet headers, and/or different length encodings).

    Or just inserting a bunch of them. Yep, it wouldn't be exact but that's where the "almost" comes in 😅

    Also: since it's meant to be ignored one could insert more content instead of just the string PGP 😁

    It's amusing to contemplate, but I'd be reluctant to use this approach 😃

    I'm not seriously suggesting it but you know my knack for inventing Rube Goldberg machines 🙃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions