On Tue, Mar 22, 2016 at 2:45 PM, Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
Till Maas wrote:
> I guess it might even make the new hotness do scratch builds with
> verified tarballs, since iirc it updates both the tarball and the
> signature and then %prep makes sure that they are verified.
I suppose so, at least if the key is specified as only a filename. What
will it do if a URL to the key is provided, and the key at that location
has been modified? Will it replace the key with the modified one in the
scratch build, or will it leave the key alone when there is no version
number in the filename?
If Werner Koch is willing to make changes to benefit this type of use
case, I don't suppose he could be persuaded to define a canonical,
reasonably compact fingerprint format?
$ gpg --verify-by-fingerprint "gpg-ecdsa-nfakjwejfhasasfewiahcalkweec"
filename filename.sig [optional path to keyring or whatever if not
embedded in the sig]
would be quite handy.
256 bits of fingerprint would be sufficient for the forseeable future
against anything except multiple-target quantum attacks. With
signature schemes like ECDSA, simply encoding the literal public key
would work fine, too.
<not-yet-relevant>Off the top of my head, a multiple-target quantum
attack involves finding any of 2^t needles in a haystack of size 2^b,
for a probability of 2^(t-b) that any given needle wins. Using a
practical upper bound of t=128 and requiring that the adversary spend
2^128 effort on an attack gives t-b ~ 256 or b ~ 384 bits for security
against Grover-style attacks.
Of course, trying to defend against that attack using 384-bit
fingerprints over ECDSA keys is totally pointless. The world should
seriously consider switching to SPHINCS or similar for software
verification.
</not-yet-relevant>
>
> Björn Persson
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>