Opened 3 years ago

Last modified 6 months ago

#22123 new enhancement

baseXX API strictness

Reported by: catalyst Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: technical-debt, refactor, api, ex-catalyst-20190619
Cc: catalyst Actual Points:
Parent ID: #19531 Points:
Reviewer: Sponsor:

Description

We should think about how strict to make decoders for our baseXX APIs. In some situations, it improves security to only have a single canonical encoding for any particular value. We should see where this is true in our code.

Base16

  • case sensitivity (currently case-insensitive)

Base32

  • case sensitivity (currently case-insensitive -- also the standard default is uppercase and we use lowercase)
  • padding strictness (currently no padding at all, even with odd lengths?)
  • trailing bits strictness (in an odd-length decode, there might be leftover bits in the final non-padding character. for a canonical encoding, they should all be zero)

Base64

  • padding strictness
    • padding = characters only at end (currently any padding characters terminate decoding)
    • correct number of padding characters (currently not checked)
  • whitespace? (maybe only if explicitly allowed?) currently we allow any whitespace
  • trailing bits strictness (in an odd-length decode, there might be leftover bits in the final non-padding character. for a canonical encoding, they should all be zero)

Child Tickets

Change History (4)

comment:1 Changed 3 years ago by catalyst

Milestone: Tor: unspecified
Owner: set to catalyst
Status: newassigned

comment:2 Changed 2 years ago by nickm

Keywords: technical-debt refactor api added

comment:3 Changed 6 months ago by catalyst

Cc: catalyst added
Keywords: ex-catalyst-20190619 added
Owner: catalyst deleted

Remove myself from tickets I'm not actively working on.

comment:4 Changed 6 months ago by catalyst

Status: assignednew
Note: See TracTickets for help on using tickets.