Hi Bob,
On Thu, 27 Apr 2023 19:55:42 +0200,
Robert Relyea wrote:
> A good read indeed.
Thanks, I'm happy you enjoyed it :).
> I do wonder about the error message:
>
> because: SHA1 is not considered secure since 1970-01-01T00:00:00Z
>
> I'm not sure where the date came from, but SHA1 wasn't published until 1993. 1970-01-01 looks like an epic of
> some kind. If you must include a 'not considered secure' date it should be something between 2010 and 2017
> (2010 when peole started worrying about sha1, 2011 and 2013 when NIST said 'stop using it' and 2017 when
> Google (ironically - since they are the ones still signing packages with it) actually broke it). Probably best to
> drop the not considered secure if the received date is null.
Good catch!
In Sequoia, we have high-level policy objects that are passed to every
method that directly or indirectly does a cryptographic operation.
Before doing something that relies on cryptography, a method checks
that the operation is allowed by the policy. If the policy returns an
error, the caller adds some additional context to the error message,
and then returns the error. For instance, before using a signature in
a context that requires second pre-image resistance, a method might
do:
```rust
policy.signature(&sig, HashAlgoSecurity::SecondPreImageResistance)
.context("Checking ...")?;
```
Our `StandardPolicy` associates a cutoff time with each algorithm. By
default, SHA-1 is considered acceptable in a context that requires
collision resistance until 2013, and acceptable in a context that
requires second pre-image resistance until 2023:
https://docs.sequoia-pgp.org/src/sequoia_openpgp/policy.rs.html#628
https://docs.sequoia-pgp.org/src/sequoia_openpgp/policy.rs.html#646
We had two use cases in mind when we designed the cutoff system.
First, using cutoffs, it is possible to sunset an algorithm. For
instance, we released version 1.0 of sequoia-openpgp in 2020. At that
time, the world already knew that SHA-1 was broken. To allow a
transition period, we decided to set the cutoff for SHA-1 to 2023.
(We already worked on tooling to help with the transition, like
`sq-keyring-linter`, https://gitlab.com/sequoia-pgp/keyring-linter .)
In this way, no software update was required to disable SHA-1; all
Sequoia users disabled SHA-1 at the same time.
Second, OpenPGP is often used to work with archived data. When
verifying a signature, we should apply the policy from the time the
signed data was initially received. (If we don't know when the data
was received, then we conservatively assume the current time.) This
means if I have a signature that relies on SHA-1, and I store the data
on a trusted medium, then I can use the time that it was stored as the
reference time, like so:
```shell
$ sq verify --time 20080428 /tmp/msg.asc
```
When we spoke about this with the Fedora Crypto Policy team, they
decided to not use cutoffs, but a simpler binary allowed / not
allowed. Since OpenPGP time started on January 1, 1970, setting the
cutoff time to January 1, 1970 means that an algorithm is always
considered to be broken. And, that's how it is implemented, and why
the error message includes that time.
That said, yes we realize the error is confusing, and we plan to add a
special error message for this case:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/1000
Thanks!
:) Neal
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
