Re: Critical vulnerability in Sunlight key generation - weak seed acceptance

[Filippo Valsorda]

Hi Pierre,

Thank you for reporting this. I don't consider it a security vulnerability, in the same way it's not a vulnerability that all log implementations let the operator configure an RFC 9500 test key.

Sunlight does reject empty seeds since v0.4.0 and directs the operator to generate the seed from /dev/urandom (as you noted in the Details section), so what you are reporting amounts to the observation that Sunlight doesn't attempt to estimate the entropy of the seed in case the operator specifically produces a weak one with a different command. That is not common practice, and is essentially impossible in cases like

    echo "        " | openssl dgst -sha256 -binary > seed.bin

As Andrew Ayer pointed out in https://github.com/FiloSottile/sunlight/issues/35, there is still space to mitigate misconfiguration risk by rejecting seeds that aren't exactly 32 bytes long, and by implementing seed generation functionality in sunlight-keygen. Those changes are planned as part of a set of usability improvements for v1.0.0.

There is no need for an embargo, so I am cc'ing ct-policy for transparency.

Cheers,

Filippo

2025-07-02 14:20 GMT+02:00 Pierre Barre <pie...@barre.sh>:

Hi Filippo,

I discovered a critical security vulnerability in Sunlight's key generation that allows predictable private keys for CT logs.

Both sunlight-keygen and sunlight accept weak/empty seed files without validation, using them to derive deterministic keys. This allows attackers to recreate private keys and impersonate CT logs.

I accidentally found this while benchmarking - I used 'echo "                         " > seed' to quickly create a seed file, and Sunlight accepted it without warnings.

Details:

- cmd/sunlight-keygen/keygen.go:29 - No validation at all

- cmd/sunlight/main.go:447-453, 608-614 - Only checks length >=32 bytes, not entropy

- No user warnings about seed quality requirements

- Code comments mentions /dev/urandom but doesn't emphasize criticality

Impact:

- Predictable CT log private keys

- Potential impersonation of production CT logs

- Undermines web PKI trust

Recommendation:

Derive keys from app-generated cryptographically secure random seeds instead of user-provided files.

I've already requested a CVE ID for this issue from MITRE. I wanted to inform you directly so we can coordinate on the fix and disclosure timeline. Happy to provide more details or discuss remediation.

Best,

Pierre

[Pierre Barre]

Hi Filippo,

Thanks for the response. I understand your perspective, but I respectfully maintain this is a security vulnerability.

Your length >= 32 check shows you care about seed quality, but accepting 32 spaces undermines that intent. I discovered this accidentally while benchmarking - the validation gave me false confidence the seed was secure.

Even worse, a seed file could become corrupted (truncated, filled with nulls, or FS errors) and still pass your check. This isn't about detecting all weak entropy, but catching obvious failures before they compromise production keys.

Best,

Pierre

[Filippo Valsorda]

2025-07-02 22:32 GMT+02:00 Pierre Barre <pie...@barre.sh>:

Hi Filippo

I see you've just committed fixes that implement exactly what I reported:

- "cmd/sunlight-keygen: actually generate the seed" -

- "cmd/sunlight: check it is exactly 32 bytes"

This directly contradicts your public statement that this is "not a security vulnerability." Publicly dismissing a security report while silently patching it violates responsible disclosure ethics and denies proper credit. This undermines trust in the security process.

Hi Pierre,

I see why you might be confused but those two commits are implementing specific suggestions by Andrew Ayer provided at https://github.com/FiloSottile/sunlight/issues/35, which is linked from both commit messages.

Issue #35 was opened at 2025-07-01 21:01 GMT+02:00 and it says:

Sunlight should reject seeds that aren't exactly 32 bytes long, [...]

sunlight-keygen should be responsible for generating the seed. [...]

I received your email at 2025-07-02 14:20 GMT+02:00, and in my reply I said:

As Andrew Ayer pointed out in https://github.com/FiloSottile/sunlight/issues/35, there is still space to mitigate misconfiguration risk by rejecting seeds that aren't exactly 32 bytes long, and by implementing seed generation functionality in sunlight-keygen. Those changes are planned as part of a set of usability improvements for v1.0.0.

Anyway, I am happy to hear that your security concerns are assuaged.

Again, there is no need to have these conversations in private, so cc'ing ct-policy for transparency.

Cheers,

Filippo

I'm asking you to:

1. Acknowledge these were legitimate security concerns

2. Ensure proper credit in any changelog/advisory

3. Coordinate on the CVE process Let's handle this properly.

Will you work with me on this?

Best,

Pierre

[Andrew Ayer]

On Thu, 03 Jul 2025 02:20:28 +0200
"Filippo Valsorda" <fil...@ml.filippo.io> wrote:

> 2025-07-02 22:32 GMT+02:00 Pierre Barre <pie...@barre.sh>:
> > Hi Filippo
> >
> > I see you've just committed fixes that implement exactly what I
> > reported:
> >
> > - "cmd/sunlight-keygen: actually generate the seed" -
> > - "cmd/sunlight: check it is exactly 32 bytes"
> >
> > This directly contradicts your public statement that this is "not a
> > security vulnerability." Publicly dismissing a security report
> > while silently patching it violates responsible disclosure ethics
> > and denies proper credit. This undermines trust in the security
> > process.
>
> Hi Pierre,
>
> I see why you might be confused but those two commits are
> implementing specific suggestions by Andrew Ayer provided at
> https://github.com/FiloSottile/sunlight/issues/35, which is linked
> from both commit messages.
>
> Issue #35 was opened at 2025-07-01 21:01 GMT+02:00 and it says:
>
> > Sunlight should reject seeds that aren't exactly 32 bytes long,
> > [...]
> >
> > sunlight-keygen should be responsible for generating the seed. [...]

For the avoidance of doubt, I made these suggestions to improve usability and mitigate a potential misconfiguration risk. I did not and still do not consider this a security vulnerability.

Regards,
Andrew

[Joe DeBlasio - Google]

Hi folks,

After my warning in the previous thread, Pierre was banned from posting to this forum. In this thread, since Filippo addressed Pierre directly and it seemed appropriate to let Pierre respond to the list, we lifted the ban for his initial response. Subsequent replies, however, have drifted again to the adversarial and out of line. His ban remains in effect.

Since we're now in a position where one of the primary participants can't participate, please consider this thread closed.

Thank you,

Joe