TOTP Secret Base32 Padding Check

Check canonical TOTP secret Base32 padding/unused bits with explicit unpadded policy, not seed strength, OTP generation or provisioning verification.

Description

Base32 encodes bytes as alphabet symbols with optional format-specific padding.

Base32 encodes bytes as alphabet symbols with optional format-specific padding.1

Canonical trailing pad bits concern representation rather than secret strength or TOTP generation. Use TOTP Secret Base32 Padding Check to evaluate the supplied inputs under the specific model below.

When to use TOTP Secret Base32 Padding Check

Use TOTP Secret Base32 Padding Check to evaluate the supplied inputs under the specific model below. Choose the intended encoding, alphabet or check and keep the exact character, key and measurement conventions described below.

How to use TOTP Secret Base32 Padding Check and understand its results

  1. Choose the intended encoding, alphabet or check and keep the exact character, key and measurement conventions described below.
  2. Enter Secret base32, Allow unpadded using the field table and validation rules below, then run the tool.
  3. Read Decoded secret bytes, Padding characters, Canonical padding and interpret units, signs, ordering and placeholders as explained below.
  4. If the tool reports an input error, correct that field and rerun. A successful false result, empty match list or unknown-evidence placeholder has the specific meaning described here; check the limitations before applying the result.
Input fieldMeaningValue typeRequirement
secretBase32Secret base32stringRequired; constraints below
allowUnpaddedAllow unpaddedbooleanRequired; constraints below

Enter a nonempty uppercase standard Base32 string using A–Z and 2–7, at most 6560 characters including trailing padding, and a flag permitting unpadded form. Allowed raw-length remainders modulo 8 are 0,2,4,5,7, requiring 0,6,4,3,1 padding characters respectively. When unpadded form is not permitted, that exact padding is required; unused final bits must be zero. Return floor(rawLength×5/8) decoded bytes and whether supplied padding is canonical. No TOTP code, secret entropy or authenticator enrollment is checked.

decodedBytes = floor(5×rawLength/8); canonicalPadding = actualPadding==requiredPadding

Field order, units and branch conditions follow the implementation explanation above.

Output fieldMeaningValue type
decodedSecretBytesDecoded secret bytesnumber
paddingCharactersPadding charactersnumber
canonicalPaddingCanonical paddingboolean
json
{
  "input": {
    "secretBase32": "MY======",
    "allowUnpadded": false
  },
  "output": {
    "decodedSecretBytes": 1,
    "paddingCharacters": 6,
    "canonicalPadding": true
  }
}

Limitations and assumptions

Canonical Base32 encodings require zero unused pad bits. A decodable byte length alone does not demonstrate the entropy of a TOTP secret.2

Canonical trailing pad bits concern representation rather than secret strength or TOTP generation. Apply the exact scope and assumptions described above.

All listed fields require explicit values. Unexpected fields, incorrect types, nonfinite numbers and sparse arrays fail validation. Domain-specific bounds, alignments and supported tokens are stated above; extremely large inputs or outputs can also be rejected. These errors differ from successful results such as false, no matches or unknown evidence.

Alternative or Complementary methods

Use CSP Nonce Base64 Length Bits Check for a related task: A CSP nonce's encoded byte length is distinct from its unpredictable generation and per-response use.

Use Recovery Code Group Format Check for a related task: Recovery-code formatting depends on an explicit alphabet, separator and group lengths.

References

  1. TOTP Secret Base32 Padding Check — tool.io

  2. RFC 4648: Base-N Encodings — IETF

Similar or alternative tools

Don't forget to set a bookmark for tool.io!
Privacy | Imprint | Cookies