signify-openbsd

Development
1

https://www.openbsd.org/papers/bsdcan-signify.html

https://kushaldas.in/posts/using-signify-tool-for-sign-and-verification.html

https://manpages.debian.org/signify-openbsd

1 Like
2

I am considering to sign Whonix releases to provide an alternative to gnupg for verification. However, signify does not allow to embed time stamps or files names directly. It does not have a trusted comment feature.

minisign (compatible with signify) has a trusted comment feature, but it’s not available from packages.debian.org:
RFP: minisign – A dead simple tool to sign files and verify signatures

Therefore it’s not trivial to protect from rollback attacks / file name changes. It would require to create a text file that describes the file (filename, hash, time stamp) that is actually to be verified. (Similar to verifying a sha512 file to then using sha512sums to verify the actual file.) However, that is usability wise a cumbersome process so not much gained from that.

We could tell users to check the version number before importing VMs.

  • That is easy with Whonix VirtualBox since it shows Whonix build version before importing.
  • For Whonix KVM? We could ship a text file inside the libvirt.xz archive which states its version number.

And then when an old version was downloaded, simply abort.

User documentation (generally, not Whonix verification):

related:

1 Like
3

Signify is great. It doesn’t have some of the problems GPG does and is also used by GrapheneOS (the project hardened_malloc was created for).

1 Like
4

Direct signing of files is implemented but untested.

https://github.com/Whonix/Whonix/commit/486b55bd13bd74b4ed0a1a8f76cbbc6cf492d47c

Even if its working, it won’t be released/documented before the next release.

Related:

1 Like
5

signify-openbsd -S -s /home/user/.signify/keyname.sec -m /home/user/whonix_binary/Whonix-XFCE-15.0.0.3.6.ova

signify-openbsd: msg too large in /home/user/whonix_binary/Whonix-XFCE-15.0.0.3.6.ova

Cannot sign releases directly.

1 Like
6

This is now possible and documented:

Related poll:

7

signify feature request:

8

Debian package signify-openbsd links to that issue tracker. But I am not sure that’s the official issue tracker or upstream is reading it.

Quote signify(1) - OpenBSD manual pages

Ted Unangst <[tedu@openbsd.org](mailto:tedu@openbsd.org)> and Marc Espie <[espie@openbsd.org](mailto:espie@openbsd.org)>.

E-mail sent.

subject:

signify issue tracker

content:

Hi,

is there a public issue tracker for signify?

Not sure it is Issues · aperezdc/signify · GitHub. That is what Debian links to.

Anyhow. I’ve posted a bug report or feature request. Depending on how you look on it.

large file support · Issue #42 · aperezdc/signify · GitHub

Created a 2G file for test purposes.

fallocate -l 2G test.img

Tried to sign it.

signify-openbsd -S -s ./keyname.sec -m ./test.img -x ./test.img.sig

result:

signify-openbsd: msg too large in ./test.img

Could you please add support for signing arbitrarily large files?

Cheers,
Patrick

9

Marc Espie:

You can sign gzip files of (more or less) arbitrary sizes, with “verification
on the fly” as an added feature. I would recommend moving to that if you
need really really large file signatures.

Also note that the current size limitation is directly linked to being
able to put everything that gets signed in memory.

You could change the limit, it wouldn’t change the precondition.

I really advise signing gzip files if that matters, OR adapting the
strategy in such a case.

By essence, hash functions require the full signed data to be in memory.

As far as I can tell, the gzip scheme (hash 64K blocks, and sign the hashes)
is resilient to any known attack, but I’m not a professional cryptographer.

10

A reply was posted here: large file support · Issue #42 · aperezdc/signify · GitHub