V1.10.0 release is Cryptographically Sound (says this nerd)

1

I have good news for anyone who has been following the questions about the cryptographic soundness of the new releases. If you go on a long scavenger hunt, you can properly verify the new release as being signed by Alajandro Garcia, who has signed previous releases.

First, you mist ignore the page https://bisq.downloads, as the released file(s) on this page are not the same ones that Alejandro has recently signed, and anyway the key on this page which belongs to Alejandro expired in 2024(!!!). It’s an inexcusable lapse, but not cryptographically important so let’s ignore that.

Second, if you want to verify the file(s) using Alejandro’s key you will need to have already downloaded Alejandro Garcia’s key prior to the exploit. That’s because in theory, a key could be swapped or even changed (maybe?) and so we can only trust the keys we already had. Luckily, I had one, which I used to verify previous releases.

Third, you will need to go, not to the https://bisq.downloads page, but to the GitHub page for the project, which you can find here: Releases ¡ bisq-network/bisq ¡ GitHub

You will want to download the release file for your architecture, and then do not download the .asc file that corresponds. That is because these are not signed with Alejandro’s key, and only Alejandro’s key has meaning (until Alejandro signs Henrik’s key, as was promised here: Update 4 about Bisq Exploit response - #9 by suddenwhipvapor )

[UPDATE: this has been done! We can trust Henrik’s key now: Henrik's PGP key, signed by Alejandro . And using his key is easier than what I will explain below.]

Instead, you want to download https://github.com/bisq-network/bisq/releases/download/v1.10.0/partial_signatures_by_E222AA02.zip. Once you unzip this, you will see four files which are signatures of release files. If your release file does not match one of these four, I think you are out of luck unless Alejandro produces a signature of your build, or until he signs Henrik’s key (and this new version of Henrik’s key is added to the release files). [UPDATE: ←-which has been done!]

Then you go to the computer you own which has the pre-exploit version of Alejandro’s key, and you can verify the release with the .asc, as follows:

% gpg --verify Bisq-64bit-1.10.0.deb.asc Bisq-64bit-1.10.0.deb
gpg: Signature made Fri 15 May 2026 05:02:40 PM UTC
gpg: using RSA key B493319106CC3D1F252E19CBF806F422E222AA02
gpg: Good signature from “Alejandro García alejandro.garcia@disroot.org” [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: B493 3191 06CC 3D1F 252E 19CB F806 F422 E222 AA02

Please note that the “WARNING” is not to be concerned about, as this only indicates that I do not personally attest that this key belongs to Alejandro, as he and I have never met. But the “Good signature” indicates that the key I have on my computer for Alejandro, which is the same key which signed prior releases, is actually the key which signed the two files I downloaded from Releases · bisq-network/bisq · GitHub .

Thus, cryptographic rigor is satisfied.

Further notes:

  • the fact that the website https://bisq.network has a link for “All Downloads,” which points to https://bisq.downloads, should indicate that this page has the “master” copy for Bisq releases. But it doesn’t. There is only Alejandro’s key on this page, and it is a version that expired in 2024. This is not cryptographically important, but certainly unprofessional. Perhaps “All Downloads” should link to Releases ¡ bisq-network/bisq ¡ GitHub ?

  • Alejandro and Henrik might both consider uploaded their keys to the keyserver system, and updating them when they make changes (such as changing the expiration date, or signing each others’ keys) as this provides an “out of band” method of reaching the keys. This could be important in the future if an exploit takes over the Bisq website, or its GitHub page.

  • Alejandro’s current key is set to expire in October of this year. That’s not very long! It would be smart for Alejandro to either extend his key, or to create a new key and sign that key with his old key, and ask Henrik to also sign this new key.

  • A lot of projects prefer to create one file, for example “v1.10.0-hashes.txt” which contains the SHA512 hashes for each file in the release. Then each developer would sign this file, and it would remove the need to sign each individual release file. It has equivalent cryptographic rigor, and it might be easier to include in the work queue? This is just a friendly suggestion.

  • the question about cryptographic rigor is absolutely essential to trusting a project, especially after an exploit. This whole process should have been very simple, but it was made complicated by (a) a confusing scattering of files (b) lack of “best practices” for using the signing keys, and most importantly because of the belligerent, unprofessional, thin-skinned, and cryptographically ignorant responses of @suddenwhipvapor. This person banned another user for bringing up the subject, lied about the reason for banning this person (as the excuse given is disproven by the timeline), threatened to ban me for bringing up this issue, and generally acted as like an imperious, but cryptographically ignorant, despot, who confused valid cryptographic questions with an interpersonal “flare-up”. I feel badly calling someone out personally, but lack of professionalism almost led to lost trust in an important project.

  • Alejandro and Henrik should sign each others’ keys, and release those updated keys with each release. They must both also sign keys by new developers in the future, and must sign any new keys they create to use as release signing keys. This is how the “web of trust” works, and it’s important to take it seriously.

Lastly, thank you to the developers for handling this exploit, and for their hard work on this excellent piece of software.

1 Like