Hi I’m new here, I’ve had trouble with the Keys myself, I’ve recognized your issue with my own verification.
Used AI to help with verification, saw different outputs. A source mentioned a Google Dox document that gave that wrong key number. AI uses the wrong sources. It’s not a hallucination, the same wrong key came up with different AI.
Could this be a deliberate thing?
Also, how do I verify the real Qubes.iso? It’s really technical and convoluted.
I’m assuming you have read the docs.
It would be really helpful if you could say what you find difficult.
The aim is that you can follow the guide, and if something is not clear
we should know. You can make a great contribution to Qubes by helping
here.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Hi! I’ve tried reading the docs, what I struggle with is how the key verification process is explained, there is a lot of information with a lot of technical details.
This is what I have been able to understand so far:
-The Qubes Master Key = the original main Key signed by a verified original member of the Qubes team. This is what every .iso download needs to have included to compare with, to verify that it is a Real Qubes download, not a compromised fake.
Qubes version can be faked to include the Master Key, therefore a second official team member verifies the Qubes version download by stacking another Key, atop to the Master Key, (for each new Qubes version). Master Key stays the same.
I dont know if I understand it correctly, but this is how I understood it. Please correct me for misunderstanding
The steps to verify if real or forgery Qubes version download is to compare the Master Key + version Key with the Key inside the download file. This is done via compare code. (“fingerprint” for example).
I’ve probably missed a lot of the process, feel free to explain how to safely verify the Key, and why it is supposed to be safe, and not forgable. (I still think that anyone could still fake a download).
Like: If any one can compare the download Key with the original+ version Key than they know the original+version so they can just fake that too right?
I agree that the docs contain a lot of technical details that can swamp
users. But it looks to me as if you want that technical level of
understanding, instead of just following a series of steps.
That’s pretty close.
I’m not quite sure what you mean by “Qubes version can be faked to
include the Master Key”.
The point is that each release is signed with a release specific key and that key is signed with the Master Key.
So the process is:
Get copies of the Master Key from multiple sources.
Confirm that they have fingerprint 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
Import one of the validated keys and set trust level to ultimate.
Get copies of the Release signing key from multiple sources.
Verify one is signed with the Master Key.
Import that verified key.
Use that verified key to check the download.
Oh, and welcome to Qubes.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
-The Qubes Master Key = the original main Key signed by a verified original member of the Qubes team.
The Qubes Master Signing Key is the root of the complete trust chain. According to Verifying signatures — Qubes OS Documentation, it has the key id 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494.
In the documentation you can find several ways to get and import them.
You have to set the trust of that key, thats described on the docu website along with the check of the fingerprint.
This is what every .iso download needs to have included to compare with, to verify that it is a Real Qubes download, not a compromised fake.
No.
The feature, what are you searching for, is not the fact, that the iso contains any key, it is the fact, that the iso is signed by a key, thats complete different topic.
If only one byte of the iso is changed, the signature is not valid anymore and you will see it, when you check the signature of the downloaded iso.
The several releases are signed by an Qubes Release Key, for every release version a new one will be created and used.
That key is signed (authorized) by the Qubes Master Key. If you import that Qubes Release Key, you can check, if the Release Key is really signed by the Master Key and therefore legally and correct.
So, you have a chain:
Qubes Master Key → Qubes Release Key - Qubes ISO
Qubes version can be faked to include the Master Key, therefore a second official team member verifies the Qubes version download by stacking another Key, atop to the Master Key, (for each new Qubes version). Master Key stays the same.
No.
No Key can be stacked atop of the Qubes Master Key, the Qubes Master Key is the ultimate root of the chain.
And noone can fake any key for a fake iso, because the faked key is not signed by the Qubes Master Key and therefore not legally.
PGP/GPG has the concept of the Chain-Of-Trust. If you trust the Qubes Master Key, you automatically trust the Qubes Release Key (because it is signed by the trusted QMK).
Hi everyone, thank you for all the replies!As I understand from your comments:
The Qubes Release Key gets updated, but Signed by Master Key.
Master Key never changes, is stuck in vault somewhere and never ever gets out or changed or tampered with (assuming), Release Key changes with every new release. So has to be “verified” by Master Key to be legit.
That seems to be understandable.
The decentralized Model of Trust is understandable, but it could also be a risk if too many fake Keys are in circulation as with the AI with the false Key Source, and perhaps even AI could come up with random Keys, if one tampered .iso file happens to correspondent with a “fake Master Key circulating” because enough AI generated sources falsely identify it as “real”, the entire validity of a Master Key is gone. I guess that is something that comes up with living in AI age, potentially a malicious large group, like perhaps a government or criminal network could plant fake Master Key’s as well, with AI it just goes a lot faster I think.
How does that code to check the Keys verify the Keys? It is comparing the Signatures with the .iso, if it has been Signed? I’ve read the Keys are a string of numbers, some sort of cryptographic? Where in that .iso is it hiding? (I’m sorry if this sounds like a dumb noob question, I dont know a lot about Keys in programs XD, forgive my childnesses.
You mentioned that as soon as the .iso has been tampered with, the Check for the “is it Signed By the Key’s or not” does not give a positive “yes this is Signed” or “check” therefore false key.
So the Key is in the code of the .iso file? I downloaded the Master Key and the Release Key, but they are separate from the .iso file. The gpg code is then also web of trust based? It cant have been tampered with, to give a false positive?
So to sum it up if I understand correctly,
Trust Chain: Master Key (vault based, never changeble and Verified by Master Key "distributed"holders decentralized Model of Trust)–> Signes the Release Key → who in turn Signes the .iso by checking if = the Same Key Signed in .iso file, thus true .iso distribution by the gpg tool?
Its basically like just walking an important document copy to the Boss and Boss Assistant, to ask them “hey is this your handwriting and signature? Is this copy a real copy from an actual document that you have made Boss? And Assistent, is the copy machine not tampered with?” or something like that?
And to do the Sig check, we need Web of Trust gpg tool (linux example), for “asking and comparing the Boss and Assistants handwriting and siganture?”
PGP is able to generate a detached signature which is stored separately
from the data it signs. So the original data is unchanged. You will see
that this is the sort of signature provided for the ISO.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
The key is nowhere hidden. The scheme works differently from “normal” symmetric cryptography, because it uses asymmetric cryptography. Let me explain.
Of the keys we are talking about - the Qubes Master Signing Key and the Release Keys - each is, in fact, two different keys. For that, you may think of these keys consisting of two parts, which are mathematically connected, but different, and it is not possible to compute one of them from the other. One part is kept secret and used only for signing something, and the other part can be published anywhere and is used to check signatures. This is just what can be downloaded from the Qubes website.
For the .iso, the process works as follows: Using a special cryptographic hash function, the contents of the .iso are somewhat summed up, creating a long numeric value, called the hash of the file.
It is mathematically nearly impossible to change the .iso in such a way that you still get the same hash value. If the hash function is sound, the probability of getting the same hash value for different .iso files is extremely small. For instance, the SHA-256 algorithm creates a value consisting of a number which has 256 binary digits and changes unpredictably if even one bit in the .sio file is changed. So the probability is 1 / 2^^256, which is pretty small. Even AI-based attacks cannot change this, as long as the mathematics used are correct.
This hash value is, for the external signatures used here, stored nowhere. It can be published because you can compute it yourself by using that hash function. To be sure you get the right value, you may compute it several times on different systems, e.g., Windows, Linux, and so on. For several different algorithms, these hash values have been published in the Digests file that is provided on the download page. So, even if one algorithm should fail, like it occurred for MD5, there are other ones still believed to have the right properties.
Now, if you get a fake .iso, you may also get a fake Digests file, so that everything seems okay. So you need a way to find out if you have the real things.
For this, the hash value is encrypted with the secret part of the Qubes Release Key. This can be done only by the developers, because for that operation, the secret part of the key is needed, and no other key can be used. It is the responsibility of the developers to ensure that no one can steal that part of the key. But note that the complete process does not require giving this secret to anyone else.
The signature is just this encrypted hash value and can be freely published. It can be checked by anyone having the public part of the Qubes Release Key by using that part to decrypt the signature. The result will be just the hash value computed by the developers. No one else could have created a signature that would yield that same hash value, as long as they don’t have the secret part of the key.
Now you can compare the original hash value computed by the developers with the one that you computed from your .sio file. If they are the same, the .iso file must be the same one that the developers used to greater their hash value and the encrypted signature.
Now there remains just one Question: How do you know that you have the correct public part of the Qubes Release Key? Well, that’s now quite simple: It is signed by the Qubes Master Signing Key, and you had to check that signature the same way. And that signature is trustworthy as well, as long as the secret part of the Qubes Master Signing Key is not stolen - again, the responsibility of the developers. That’s the basic idea of the Web of Trust.
The only way to check whether you have the real, original Qubes Master Signing Key is to check its fingerprint, which again is a hash value of the binary data of the key and thus a reliable proof that the key is the original one. This fingerprint is published on the Qubes website, but also on a lot of different other places. So, if you find several independent places showing the same fingerprint, it is very probable - but not absolutely sure - that it is the correct one.
As there is no way to compute the secret parts of the keys from any publicly available information - even using AI techniques - it comes down to three questions:
Do you trust the mathematics used? (If not, you should never do such a thing as home banking, as they use the same techniques!)
Do you trust the software that you use for creating your copy of the hash value and for decrypting the encrypted hash value contained in the signature? To increase that trust, you may perform the operations using different implementations in different software environments.
Do you trust the developers? (If not, why should you use their software at all!)
In my opinion, it’s much better to trust the Qubes environment and its developers than, say, M$. Or to make it still worse, Donald the orange gangster!
You make a good point about, what to trust and what not, indeed I know for banking it is also used, inlcuding crypto coins.
Other factors I trust less, as you mentioned, we can only hope the developers have the best in mind. Or are not compromised. They even stated it on the documents somewhere I believe, “don’t automatically trust us, even if this warning comes from us”. A healthy attitude for things like this, and a responsible warning.
I think I’m beginning to understand the basic physiology of the Web Of Trust and cryptography of Qubes,
Now I only know some small things of how cryptography works. As you mentioned: I know that it is based on math, math never changes in any place, any time, in any circumstances. (only exeption might be in singularity of black holes, since it is believed that space and time breaks or behaves differently there). Bottom line: 1+1 always equals 2 so If I’m not mistaken, that is how cryptography works, it is an equation that always has the same outcome, no one can break that, you would brake this universe to be able to do that.
You mentioned how “no one could have created a signature that would yield that same hash value, as long as they don’t have the secret part of the key”
In my childish mind when it comes to this, if you know the answer to the equation, you can copy paste the answer right? Like cheating on a math test. So I believe what your saying is that the singature is the original equation, where an “answer” in this case the hash value comes forth from. So basically we can all have the answer to the question, but no one knows what the question was, exept for the developers, who have the question, (for example answer= 2, question could be 1+1 or 4-2 or 4:2 or whatever the question equation was to get the answer: 2)
So in short, the developers have the question equation, they release the answer, copy pasting the answer would not work for faking .iso because you need the original question to get that exact answer, and since it is some super long bizarre and nearly impossibly difficult clustered up equation, it is nearly impossible in ones lifetime to finally guessing the original question equation.
Is this sort of how the encryption works, including on Qubes Key’s?
hmm, you are very close. Only with the difference, that we speak about gigantic numbers.
Think about the question:
i have 2334564532145345776889453456345
what was the two numbers, that i have multiplicated to get that result?
Solution is not solvable.
But, i f give you my private key (one of the two numbers), then it is easy to get the other one.
(for all guys, that are familar with cryptograpy: thats not correct description of an real cryptographic process, it is only for explanation of some of the based principles, for example, RSA is based on math of two primes).
so get the other key, the other number, and then it is solvable? Then you know the equation, but then you must know also the first number, but that first number is hidden (secret in a vault). So, is it then correct when I make the following assumption: that when I submit the public part of the Key, to the hidden part of the Key, that hidden part, is doing the math, and making the equation for me, resulting in a True result, (not fake one). Sort of like that? Because I dont know the other part of the equation, that other part must be the one to collect my part and make that equation. And indeed it is an infinatasmaly (however you write that XD) large number, so almost not replicable randomly. Am I getting closer or not?
That’s about it. The creator of the cryptographic keys could easily do it by multiplying two large prime numbers. You just get the product, and this won’t help you much, because both factors have a few thousand digits, and the only known way to find them is to try every prime number until it fits. It’s not impossible, but it may take you a few billion years to find the right one.
But, perhaps, some time in the future, a very clever mathematician may find a way to do it very fast. Then, we’ll really have trouble!
Yeah, I’ve heard AI + quantum computing is going to put us into big trouble with that, are people working to make shure that that is covered too? Have there been issues with AI now in the mix, with Qubes security as far as you know?
There are new types of algorithms based on properties of elliptic curves. If one type of algorithm should break down, the other one will still be untroubled. But who knows what will come sometime in the future…
Not AI directly, but Quantum Computing will render the most of the current used cryptographic algoritms useless or shrink their security drastically.
RSA will become almost breakable (Shor), the security of AES (used for example on Qubes for LUKS disc encryption), measured in bit, will be reduced by approx. 50% (Grover).
The crypt specialist works on the so called “Post Quantum Cryptograpy” currently.
I’m still trying to verify the iso, the AI I’m using keeps saying I need to verify the Release Signing Key.sig with the Release Signing Key.asc.
I cant find the signature of the release Key anywhere and now I’m a bit lost as to what the precise steps are to verify the .iso with gpg. I see conflicting steps.
So first gpg --verify qubes release-4.2-signing-key.asc.sig qubes-release-4.2-signing-key-asc.