base64-ng 1.0.2

no_std-first Base64 encoding and decoding with strict APIs and a security-heavy release process
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

# Constant-Time Assembly Review

This document records the manual generated-code review expected for
constant-time-oriented scalar decode work. It does not create a formal
cryptographic constant-time guarantee.

## Scope

Review these generated artifacts after running:

```sh
scripts/generate_ct_asm_evidence.sh
```

Expected artifacts:

- `target/release-evidence/asm/base64_ng-no-default-features.s`
- `target/release-evidence/asm/base64_ng-all-features.s`
- `target/release-evidence/asm/base64_ng-all-features-lto.s`
- `target/release-evidence/asm/MANIFEST.txt`

Review focus:

- `ct::CtEngine` decode entry points
- `ct_decode_padded`
- `ct_decode_unpadded`
- `ct_decode_padded_in_place`
- `ct_decode_unpadded_in_place`
- `ct_decode_alphabet_byte`
- `ct_mask_*` helpers
- `ct_error_gate_barrier`
- `constant_time_eq_public_len`
- `wipe_bytes` and `wipe_barrier` cleanup call boundaries

## Review Questions

- Are selected alphabet bytes scanned with fixed 64-entry symbol mapping rather
  than secret-indexed decode tables?
- Are malformed-content flags accumulated through masks instead of early
  returns inside fixed-length decode loops?
- Are branches in the reviewed ct path based only on public facts such as
  input length, padding mode, selected alphabet, and caller output capacity?
- Does generated code keep the scalar ct path independent from SIMD dispatch?
- Does `ct_error_gate_barrier` remain a separate non-inlined symbol in release
  and LTO artifacts before opaque malformed-input reporting?
- Does `constant_time_eq_public_len` remain a separate non-inlined symbol in
  release and LTO artifacts, and does the equal-length loop scan all bytes
  rather than lowering into an early-exit compare?
- Do `wipe_bytes` and `wipe_barrier` remain non-inlined cleanup call
  boundaries in release and LTO artifacts?
- Are padding length, decoded length, and final success/failure still treated
  as public by documentation and API shape?

## Current Release Position

For the `1.0.0` release:

- Assembly evidence generation is release-gated.
- Manual review is required before any future release that strengthens ct
  wording beyond "constant-time-oriented".
- The public documentation continues to use "constant-time-oriented" wording.
- No formally verified cryptographic constant-time guarantee is claimed.

## Reviewer Notes

Record release-candidate notes here before tagging a stable release:

```text
version:
rustc -Vv:
targets reviewed:
features reviewed:
assembly manifest checksum:
reviewer:
date:
notes:
```