[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Whonix Software Signature Verification Documentation Discussion - VirtualBox vs KVM - GPG / signify / codecrypt

Why do we have this chapter?

https://www.whonix.org/wiki/KVM#Verify_the_Whonix_.E2.84.A2_Images

KVM gpg verification instructions are listed here:
https://www.whonix.org/wiki/Verify_the_Whonix_images

Was quite some effort to turn this into wiki templates that work for both VirtualBox and KVM.

That chapter could perhaps be converted into using the same wiki template? Or just a link?

Then also previous instructions caused confusion

gpg: key 50C78B6F9FF2EC85: 1 signature not checked due to a missing key

Users asked about this multiple times in forums (where we misinterpreted and didn’t know what they’re talking about) and on telegram / matrix chat. Not sure my changes made it better or worse. Changed version would avoid that issue but https://www.whonix.org/wiki/Whonix_Signing_Key#Download_the_OpenPGP_Key itself has the same issue.

gpg: key 8D66066A2EEACCDA: 104 signatures not checked due to missing keys

And it’s only resolved thorugh advanced users chapter https://www.whonix.org/wiki/Whonix_Signing_Key#OpenPGP_Web_of_Trust.

How we could resolve this? Should https://www.whonix.org/wiki/Whonix_Signing_Key become a draft for a new template? We could have separate Whonix_Signing_Key wiki pages for Whonix VirtualBox and Whonix KVM?

Then for any signature not checked due to a missing key messages we could say "advanced users check Whonix_Signing_Key/VirtualBox or Whonix_Signing_Key/KVM.

I think it predates the templates. This page has the relevant steps because it refers to my key while the KVM templates are incorrect because they refer to releases signed with yours

Is there a way to suppress these confusing messages?

A template that includes steps for all versions of Whonix and the relevant subsection is linked to from each ports respective wiki page

HulaHoop via Whonix Forum:

I think it predates the templates. This page has the relevant steps because it refers to my key while the KVM templates are incorrect because they refer to releases signed with yours

Could you please update the KVM page(s) which call the wiki templates?
That should all be editable through wiki template variables. That was
why the whole exercise was done. It’s a good exercise for future use of
signify (available for VirtualBox releases already) and codecrypt
signatures.

Is there a way to suppress these confusing messages?

I haven’t found any.

A template that includes steps for all versions of Whonix and the relevant subsection is linked to from each ports respective wiki page

I am not sure I understand. What would happen with Whonix_Signing_Key
page? What subection? If we had subsections VirtualBox vs KVM then we
wouldn’t use a wiki template?

On a second thought, turning
https://www.whonix.org/wiki/Whonix_Signing_Key into a template could be
difficult. Instructions for OpenPGP Web of Trust will be different.

  • [1] Establishing my signing key through OpenPGP Web of Trust
    realistically requires establishing a trust path through Debian keyring.
  • [2] Establishing your signing key through OpenPGP Web of Trust would
    require doing [1] first (verify trust path to my key) and then use my
    key to establish trust path to your key.

But somehow template(s) either way. There’s lots of text passages which
are best when shared to keep up with gpg (that “signature not checked
due to a missing key” message seems new).

Speaking of PQ some final group candidates have software implementations available on their project sites that can sign and verify the safer stateless signatures not available in codecrypt at the moment, I will open a separate thread for this if you are interested in compiling/packaging them and I will figure out how to use them

1 Like

Just to be sure. I will paste the contents of https://www.whonix.org/wiki/KVM#Verify_the_Whonix_.E2.84.A2_Images onto the KVM section of https://www.whonix.org/wiki/Verify_the_Whonix_images and link the template from the page, Sounds good?

https://www.whonix.org/wiki/Whonix_Signing_Key can also include a link to my signing key?

Interesting.
No, I don’t think I’ll compile/package codecrypt.

APT uses gpg internally. Therefore we’re bound to a lower security level anyhow, i.e. non-PQCrypto level. If we have gpg / signify signed releases we’re on par, i.e non-PQCrypto level. PQCrypto level signed releases is a nice bonus but wouldn’t really increase security a lot.

Waiting for updated codecrypt version through Debian as usual.
https://packages.debian.org/search?keywords=codecrypt

Related:

1 Like

A lot complexity…

Now I also wonder if it’s up to us to explain how to use the OpenPGP web of trust? It is possible to verify either key through the OpenPGP web of trust. We can certainly add a hint how to do that. But do we ought to document in detail (each command and output) how to use the OpenPGP web of trust?

Due to Conceptual Challenges in Digital Signatures Verification: if we need to explain it, the user wouldn’t benefit from it anyhow?

Disadvantage of having OpenPGP web of trust documentation:

  • It makes Whonix look needlessly complicated. Most users were never aware of any software verification possibilities and never did it before. Then users don’t benefit from it anyhow. Users easily conclude it’s too difficult to use, not safe without software verification and then just download and install hidemyass or something without software verification.
  • Effort to create and maintain this documentation.

By extension this arguments could be made for all software signature verification instructions. We offer signing key, and signatures. But why Whonix must have signature verification instructions? Are we trying to fix upstream issues, that is bad usability / bad documentation? Or is it activism spreading gpg and software signature verification concepts?

From a security (non-activism) only perspective, as per Conceptual Challenges in Digital Signatures Verification: software signature verification is something users need to ask for. It’s not something vendors can offer to users.

IMO The detailed page should be moved elsewhere as a reference to interested users who might want to learn about the WoT (for some reason). The templates should instead show the simplest instructions possible and limit explanations of errors to “this can be safely ignored” and moves on to getting the user up and running.

1 Like

Not great. If it’s pasted, then it’s still duplicated, standlone, going to divert over time, not using any wiki template. And we’d have major differences on VirtualBox vs KVM verification instructions.

There are these two KVM wiki pages, based on using wiki templates:

Perhaps my software verification wiki template approach is too complicated?

A) My approach was (current at time of writing): shared software verification wiki templates with the bits which must be different being entered at a wiki page which imports the template using wiki template variables.

B) Another approach would be: no whole shared wiki template but instead move text blocks which make sense to be shared into wiki templates. Then any wiki page which needs any text block can simply re-use shared text blocks from wiki templates. There wouldn’t be any template variables. The variable (differnet VirtualBox vs KVM) parts would be directly on the wiki pages.

C) Yet another apporach would be to have fully independent wiki pages. No templates. All text blocks would be duplicated and therefore diverts more and more over time.

It’s not just 1 link. It’s ~ 5 steps with different inputs commands and output messages.

Depending how it’s implemented, that would be confusing.

There could be one chapter for VirtualBox and one for KVM.

But if we have chapters we could make https://www.whonix.org/wiki/Whonix_Signing_Key similar to https://www.whonix.org/wiki/Verify_the_virtual_machine_images_using_Linux, i.e. a link to a standalone VirtualBox and a link to a standalone KVM page.

Sounds most sane right now.

Do I need to edit anything at the moment or are you guys going to work these changes first on the long wiki edits thread?

1 Like

All done. Please review.

1 Like

Perfect thanks. I did upload the signify key to sf once upon a time. Where should I upload it to on whonix.org?

Is anyone using it? Because otherwise might not be worth the effort.

There’s currently no upload / download.
It’s just two lines for copy/paste into a file; and a gpg clearsigned version.
See:

https://www.whonix.org/wiki/Main/Whonix_Signing_Key#Download_the_signify_Key

Was requested by @madaidan on telegram. I guess @madaidan is using it. Haven’t heard any other reports yet. I’ll add a wiki comment to encourage usage reports in Whonix forums.

1 Like

Time for another poll. Draft:

Which software signature verification method would you most like to see supported?

Choice 1

gpg

Choice 2

signify

Choice 3

codecrypt

Choice 4

none


Looks good?

(related: polls collections (surveys))

Technically, codecrypt should never be the exclusive or top choice since we have the one time signature problem.

None implies “no verification at all” vs what you mean as “no preference” so best to change it to that.

1 Like

HulaHoop via Whonix Forum:

Technically, codecrypt should never be the exclusive or top choice since we have the one time signature problem.

I don’t understand that problem. Could you please point me to it?

None implies “no verification at all” vs what you mean as “no preference” so best to change it to that.

Actually meant “no verification at all” but since it’s maximum 4 choices
I’ll go with “no preference”.

1 Like

Signing anything under a stateful sig scheme with the same key more than once destroys its verification guarantees vs stateless that can withstand multiple uses. This is very likely to happen when used in a virtual environment and forgetting to backup the keychain after singing a build when its sig key counter is run down.

codecrypt only includes stateful schemes as of yet (XMSS)

Hash-based signature schemes use one-time signature schemes as their building block. A given one-time signing key can only be used to sign a single message securely. Indeed, signatures reveal part of the signing key. The security of (hash-based) one-time signature schemes relies exclusively on the security of an underlying hash function.

@Patrick I just listed my signify public key on the wiki after I finished uploading 1.4.9

Are we going to do anything more with it? List it in the download table and document the signify verification process?

1 Like

From signify-openbsd

That is a good question. Due to low interest (inquiries and poll) and due to it being complicated enough already I guess suffices as is. Perhaps improve existing documentation to include KVM. I don’t know any other project offering multiple signature schemes to compare. What do you think?

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]