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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
//! Ed25519 identity keypair — the cryptographic root of trust.
//!
//! **Invariant:** the signing key (private seed) NEVER appears in `Debug`
//! output, log lines, or error messages. The custom `Debug` impl redacts it
//! unconditionally; key-management errors carry only operational context, not
//! key material.
//!
//! **Key-acceptance invariant:** there is exactly one rule in this crate for
//! whether 32 bytes are an Ed25519 public key at all —
//! `is_usable_ed25519_public_key` — and [`Ed25519Identity::verify`] admits a
//! key if and only if that predicate does. In particular a **non-canonical
//! encoding is not a key**: `y` and `y + p` are two spellings of one point, and
//! `ed25519_dalek::VerifyingKey::from_bytes` reduces rather than rejects, so
//! the check has to be made here. Anything that decides key-ness by some other
//! means is a second copy of this rule and free to drift from it.
//!
//! Identities are obtained via [`Ed25519Identity::load_or_generate`]
//! (file-backed) or [`Ed25519Identity::from_env`] (env-var-backed, for
//! containers and CI). The two paths are independent — neither calls the
//! other.
//!
//! **Concurrency invariant:** when multiple callers — threads in one process
//! or separate processes — race `load_or_generate` on the same missing path,
//! exactly one generated seed is ever persisted and every caller returns the
//! identity for that persisted seed. Each generator writes its candidate
//! seed to a uniquely named temp file (pid + per-process counter) and
//! publishes it with a no-clobber `hard_link`; the first publisher wins, and
//! losers discard their candidate seed and load the winner's file. The key
//! file at a given path therefore never changes once created.
//!
//! Sealed payload transport uses X25519 key agreement, but the long-term keys
//! here are Ed25519. [`Ed25519Identity::x25519_static_secret`] and
//! [`Ed25519Identity::x25519_public_key`] derive the X25519 keypair from the
//! Ed25519 signing key via the standard clamped-scalar conversion, so one
//! keypair serves both signing and key agreement.
use fmt;
use Path;
use Engine;
use ;
use Signer;
use Zeroizing;
use crate;
use ;
/// Name of the environment variable read by [`Ed25519Identity::from_env`].
const KEY_ENV_VAR: &str = "LYS_IDENTITY_KEY";
/// Ed25519 identity keypair.
///
/// This is the cryptographic root of trust for the consuming domain. The
/// signing key never appears in `Debug` output. Obtain one via
/// [`Self::load_or_generate`] (file-backed) or [`Self::from_env`]
/// (env-var-backed).
/// The prime `p = 2²⁵⁵ − 19`, little-endian — the field modulus a canonical
/// Ed25519 y-coordinate must be strictly below (RFC 8032 §5.1.2).
///
/// ⛔ **This was `#[cfg(feature = "unstable-anchor")]`, on the reasoning that
/// "the only artifact class that names a key it does not itself verify with is
/// the gated `delegation` format".** The premise was true and the conclusion did
/// not follow: [`Ed25519Identity::verify`] *does* verify with the key, and it
/// was accepting a non-canonical encoding of one. The gate meant the default
/// build — the shape consumers actually get — could not have enforced the rule
/// even if it had wanted to.
const CURVE25519_FIELD_MODULUS_LE: = ;
/// Whether the y-coordinate in a compressed Ed25519 point encoding is canonical
/// — strictly less than `p` once the sign bit is masked off.
///
/// **This is checked here because `VerifyingKey::from_bytes` does not check it**,
/// which is not what one would assume from the name. Measured rather than
/// inferred: `from_bytes` accepts all-`0xff` and reports it as non-weak,
/// because decompression reduces the y-coordinate modulo `p` instead of
/// rejecting an out-of-range one. A non-canonical encoding is a second spelling
/// of a point that already has one, which is the same defect class this crate
/// refuses everywhere else in its wire formats.
///
/// **The sign bit is masked off and not otherwise checked.** `x = 0` with the
/// sign bit set is a second non-canonical spelling, of the two points with
/// `x = 0` — `y = 1` (the identity) and `y = p − 1` (the order-2 point). Both
/// are small-order, so [`is_usable_ed25519_public_key`]'s third condition
/// refuses them under either spelling and there is no encoding this masking
/// lets through. Stated because it is a gap in *this* function that another
/// condition closes, which is exactly the kind of thing that stops being true
/// silently.
/// Whether `bytes` is a public key that could ever verify anything.
///
/// Three conditions:
///
/// 1. **Canonical y-coordinate** — see [`is_canonical_y_coordinate`], and note
/// that `VerifyingKey::from_bytes` does *not* enforce this.
/// 2. **Decompresses to a curve point** at all.
/// 3. **Not small-order.** A small-order key — the identity point among them —
/// admits forged signatures for arbitrary messages, which is why strict
/// verification refuses it.
///
/// Exposed to the crate rather than to consumers, and placed here rather than
/// at its call site, because this is the one file that knows how lys decides an
/// Ed25519 key is usable. A second copy elsewhere would be free to drift out of
/// agreement with [`Ed25519Identity::verify`] while both kept passing their own
/// tests.
///
/// Two kinds of caller: artifacts that *name* a key they do not verify with — a
/// key that fails here can never authorise anything, so an artifact carrying
/// one is a signed statement that cannot mean anything — and
/// [`Ed25519Identity::verify`] itself, which admits exactly the keys this
/// predicate admits.
///
/// # This USED to be stricter than [`Ed25519Identity::verify`]
///
/// ⛔ The paragraph replaced here recorded the asymmetry as deliberate and
/// deferred: condition 1 had no counterpart in verification, because
/// `verify_strict` checks the canonical `s` scalar and small-order `R` and `A`
/// but **not** that `A`'s y-coordinate is canonically encoded, and neither does
/// `from_bytes`. It argued that closing the gap "would change shipped, ungated,
/// semver-bound behaviour on the strength of a low-severity finding, which is a
/// decision for a release rather than for this module".
///
/// That was a reasonable thing to defer and a bad thing to *leave written down*
/// as a resting state. Two notions of "a key lys will accept" in one crate is
/// the drift this function was extracted to prevent, reintroduced one level up:
/// the delegation decoder and `verify` disagreed about the same 32 bytes, and
/// nothing anywhere would have failed if they had drifted further. `verify` now
/// calls this predicate, so agreement is structural rather than reviewed.
///
/// **What that narrowed, precisely.** Only encodings with `y >= p` once the sign
/// bit is masked — the 38 strings `y ∈ {p, …, p + 18}` × 2 sign bits. Of those,
/// 14 never decompressed and were already refused by `from_bytes`; 4 (`y = p`
/// and `y = p + 1`, both signs) reduce to the order-4 and identity points and
/// were already refused by `verify_strict`'s small-order check. The remaining
/// **20 were accepted as verifying keys and now are not.** None of the 20 can
/// have had a verifying signature that anyone could produce: each is a second
/// spelling of a point with `y ∈ {3, 4, 5, 6, 9, 10, 14, 15, 16, 18}`, and
/// signing under one means holding its discrete logarithm. So the change
/// narrows the set of accepted *key encodings* and cannot change any
/// constructible `Ok` outcome — which is also why no test can distinguish the
/// two behaviours through `verify`'s return value. See the tests.
pub