1552315 - Rotate and hard code Prio public keys

Status: RESOLVED FIXED

(Data Platform and Tools Graveyard :: Operations, task)

Description

[Steven Englehardt [:englehardt]]

We've decided that we should rotate and hard code the Prio public keys prior to landing Bug 1543712.

The keys are currently specified in prefs (prio.publicKeyA and prio.publicKeyB). We should hard code them, preferably such that they'll end up in the binary or in one of our libraries to benefit from signing. When we make the move, we can also take the opportunity to rotate the keys.

Comment 1

[Steven Englehardt [:englehardt]]

Anthony, mind to post the new public keys to this bug once they're generated?

Comment 2

[Melissa O'Connor [:melissa]]

We reached out to Anthony on this and have the steps needed to do this work.

https://github.com/mozilla/python-libprio` build the docker container and then prio keygen

Comment 3

[Wesley Dawson [:whd]]

I've generated the following key pairs:

dev:
a:
public_key: 209A3CC721E661E1B00CFACFA7A647E8A9F1C6C94ED67A5088D1DF3DC4223542
b:
public_key: 6A544DABEA8AA2D00670879AB2048ECD81A460ECD0BF272DE937ABE0DFCC2538
stage:
a:
public_key: E724B5334187C7BEF270F6DFE123F7C0251685F1CD49520F38C7AA0AC7475E06
b:
public_key: 7E3034385C02E69AB540A5EC59DD22B9C79708DED700992A6DE3844E6AA3C109
prod:
a:
public_key: E780C1A9C50E3FC5A9B39469FCC92D62D2527BAE6AF76BBDEF128883FA400846
b:
public_key: F992B575840AEC202289FBF99D6C04FB2A37B1DA1CDEB1DF8036E1340D46C561

Of these, only prod should be hard-coded into the client. The others may be used for testing purposes in our testing of various components of the pipeline as per standard operating procedure.

The private keys are stored in our KMS-encrypted secrets store (currently under misc/prio.yaml since we haven't finalized the method by which this job will run).

Comment 4

[Chris H-C :chutten]

When we hardcode these keys we'll be losing test flexibility. For example, PrioEncoder.BadPublicKeys and PrioEncoder.VerifyFull become irrelevant or unimplementable with a naive implementation.

How concerned should we be about losing these tests? How much effort should we go to in order to keep this coverage?

Comment 5

[Robert Helmer [:rhelmer]]

(In reply to Chris H-C :chutten from comment #4)

When we hardcode these keys we'll be losing test flexibility. For example, PrioEncoder.BadPublicKeys and PrioEncoder.VerifyFull become irrelevant or unimplementable with a naive implementation.

How concerned should we be about losing these tests? How much effort should we go to in order to keep this coverage?

Henry suggested before that the constructor could take the public keys as arguments, which would let us preserve the flexibility to change our minds and be able to reverse the hardcoding decision without undue burden, wdyt?

Comment 6

[Chris H-C :chutten]

I went a slightly different way looking forward to a time when we may wish to rotate the keys at runtime. Take a look and let me know if that's what you were thinking?

Comment 7

[Chris H-C :chutten]

Attachment: Bug 1552315 - Hardcode the new prio keys to avoid misconfiguration. r?rhelmer

As a plus this gives us an API we could use if we ever need to rotate the keys
at runtime.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/45c8ab7db844
Hardcode the new prio keys to avoid misconfiguration. r=rhelmer

Comment 9

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/45c8ab7db844