Fucking GPG signatures, how do they work?

Yes you can have phonies in your chain of trust.

>>44196898
>how does a GPG signature guarantee that the software is legit?
It doesn't, but it guarantee that the software is the one the distributor signed and that you wasn't MITM'd

>>44196915
So you can never be 100% sure that the software you downloaded hasn't been tampered with?

>>44196964
Only if you trust the signature

>>44196964
>So you can never be 100% sure that the software you downloaded hasn't been tampered with?

well sha's and stuff are pretty safe indicators, but the point about PGP is encryption based on people whom you (optimally) trust.

That's why verifying keys is so important.
Talk to them in person, make sure they are who they are.

this is of course the optimal solution and often not applicable to casual shit but yeah, email exchanges are still pretty safe, etc.

>>44196961
I don't really understand how all this shit actually works.

Could you point me to some sites/articles that explain GPG and encryption generally from the bottom up, so that a layman can understand it?

In case of MITM, couldn't the attacker intercept the GPG signature that is being sent to me and modify it?

>>44196995
I'm specifically talking about Tor.

My concern is the following:

I go to torproject.org, but my request is intercepted and directed to a fake site, with tampered Tor package and modified GPG signature.

I download both, and when I try to check if everything is ok, my request is again intercepted and a positive response is sent back to me, not by a legitimate source but by MITM.

I know this may sound retarded, but again I have a very layman knowledge of all this.

>>44197093
If they modify the signature, they would have to modify the public key too. Otherwise, the signature would not be able to be verified.

>>44197093
>My concern is the following:
The concern is legitimate and your option to dispel all doubt is to contact the owner of the signature key and somehow verify it.

It's the only way to be truly sure cause anyone can sign a message/file and simply use the email/name of the person they are trying to impersonate

>>44196964
You can never be 100% sure that you won't have a heart attack right this second, or get killed by a meteor.

>>44197148
>It's the only way to be truly sure cause anyone can sign a message/file
with their own public key, of course, as
>>44197138
>If they modify the signature, they would have to modify the public key too. Otherwise, the signature would not be able to be verified.
points out.

people can be impersonated, but they need the public key etc for that.

Also, the signature also depends on the file/message.

So they can't just copypaste the signature and change the content of the message.

try it.

gpg --clearsign
type something, finish with control-D

modify the message but keep the signature block as it is, then
gpg --verify
it.

it will complain that the signature is bad.

>>44197168
>but they need the public key etc for that.
not the key of the person they are trying to impersonate, just a public key they have created with a fake identity, but passed off as the pubkey of the actual person.

they can not take the pubkey of the original and then forge some signature with it, etc.

well not practically anyway, nothing is 100% crack safe.

>>44197300
>they can not take the pubkey of the original and then forge some signature with it, etc.
and knowing this, if you have verified that pubkey of the original owner, you will be able to tell fakes from the original.

https://www.youtube.com/watch?v=6NcDVERzMGw

>>44196898
Let's assume you are a trap and your new name is Alice, and you're trying to send a secure message to your new fuccboi, Bob.
You then create a keypair, that is, a public key and a private key, your idiot bf does the same, and you exchange public keys. That's how asymmetric encryption works. You encrypt a message your recipient's public key, and only our recipient (or another person with his private key) can decrypt it. Now moving onto your actual message...
If your message is private and you wanna encrypt it, take your plaintext (that is, your message without encrypting) and encrypt it with your bf's public key. Send it. Profit.
If your message is public, but you wanna be able to prove that it's legit from you, hash that plaintext (with SHA1 or something), encrypt that hash with your private key (that's called the "signature"), and send it with the plaintext. The person on the other end hashes the plaintext, and then compares it with the hash you sent, decrypted from the signature and the public key you've previously shared. If they match, it's legit.

I hope you understand with this, faggot, because I just typed all that on my phone.

>>44197355
-----BEGIN BEGEPE SIGNED MESSAGE-----
Hash: ROT14

10/10 post, m8. I lel'd
-----BEGIN BEGEPE SIGNATURE-----
Version: Gn00BeGe v1

0uRsy5T3mTh1NK5j0OrP05t155p4m
-----END BEGEPE SIGNATURE-----

>>44197148
>The concern is legitimate and your option to dispel all doubt is to contact the owner of the signature key and somehow verify it.

But how would I know if I'm contacting the owner? Couldn't MITM impersonate the owner, in which case I'd have absolutely no way of verifying it?

>>44197300
>they can not take the pubkey of the original and then forge some signature with it, etc.

I'm barely understanding what you're saying, since my knowledge is limited, but how would I acquire the public key?

Me -> MITM -> Public key

MITM could just send me his key and I'd think it's the actual public key, no?

>The person on the other end hashes the plaintext, and then compares it with the hash you sent, decrypted from the signature and the public key you've previously shared. If they match, it's legit.

In this case, I'm the person on the other end. What if I've been conversing with MITM all along? He'd be sending me his hashed plaintext and I would have sent him my private key before that, believing I was sending it to the guy I actually wanted to send it to.

The key would check out, because I've never actually acquired the key from the actual, legit source I wanted to acquire it from.

>>44197719
>But how would I know if I'm contacting the owner? Couldn't MITM impersonate the owner, in which case I'd have absolutely no way of verifying it?

You could meet the owner, have them show you their ID, their birth certificate, meet their mother, show you their elementary school papers, etc.

There is always a way, not always feasible, but there are.

>>44197719
>how would I acquire the public key?
They need to post it somewhere.
You download/copy it and import it into your keyring.

>MITM could just send me his key and I'd think it's the actual public key, no?
Yes, they could create a key that has the same name, email address and comment as the original person.

That is why you need to verify (and possibly sign) a key.
(this is another way of knowing if a key is legit, if other people you trust have signed (vouched for) the keys legitimacy)
(this builds a web of trust, etc)

Anyway.

The three steps are:
Aquire public key (identity is, at this point unclear)
Verify key (either by talking to the owner or perhaps by signatures of trusted people)
Now you can verify the message signature.

If it matches with the verified key then congrats, you are talking to the good guy.

if it doesn't match then its tampered, etc.

But you need to verify the identity of the public key first to be sure, since it is used to create the signatures.

>>44197093
>User downloads a list of public keys from the repository or wherever
Of course, in case you were already MITM'd by this point you could be getting fake keys here.
>User downloads package
>Package gets unencrypted with the previously downloaded public key
If it fails, there is a mismatch between the private key the package has been encrypted with and the public key you downloaded. This could mean that the passwords have been downloaded wrongly or they are outdated, that the package is corrupt or that you have been MITM'd and you got a hijacked package. Of course, the package manager will not trust that package and it will not get installed.

If it gets unencrypted correctly then it gets installed because it's legit. it could also mean you have been hijacked since the moment you downloaded the list of public keys, but it is more unlikely.

>>44197872
I could generate two public keys with the same email address, same name and same description for example purposes, and only claim that one of them is legit (actually mine) but I hope that I dont have to do that.

Not that I don't want anyone to know my pubkey, it's just that I don't wanna go through the effort and most likely wont cause I'm eating a delicious yogurt with oats right now.

>>44197872
>They need to post it somewhere.
>You download/copy it and import it into your keyring.

This is my main concern:

>>44197874
>it could also mean you have been hijacked since the moment you downloaded the list of public keys, but it is more unlikely.

I know it's very unlikely, because it's too much trouble for someone to go through, but it could be possible to do so if someone was specifically targeting me.

Basically, if I was MITM'd from the start, which is highly unlikely, I would have no way of knowing it, right?

I would have been given fake public keys, private keys and fake package, and they would all appear legit.

Pretty much the only way I would know nothing was tampered with, was if I knew the owner of the package in person from before and I met them face-to-face to verify the legitimacy, right?

>>44197093
https://wiki.archlinux.org/index.php/GnuPG

>>44197994
>This is my main concern:
Yes, but how else transfer it?
Anyway, a pubkey isn't harmful in itself and you can verify it.

Once you have done that then henceforth you can be sure that it will be from the legit source if it matches up.

How you verify it is up to you, though.

>>44198030
>Yes, but how else transfer it?
>Anyway, a pubkey isn't harmful in itself and you can verify it.

But I'm saying, what if I'm getting the public key from the MITM?

>>44198003
Thanks! This is more about how to actually use them, rather then how the mechanism works. Where could I find an easy read detailing how the mechanism itself works, rather then how to use it?

>>44196898
No, but they could get you to download another GPG key too.

>>44198081
>But I'm saying, what if I'm getting the public key from the MITM?

Then you are getting it from the man in the middle.

If you have no means of verifying the identity of the pubkey then you shouldn't trust it.

But perhaps you mean it in a different way?
Like even the verification is done by MITM?

Well, obviously the verification will succeed then, cause he will be conducting it with you, and then his impersonated posts (which he did with the key he just verified with you) will be legitimately from MITM.

But it cannot be mixed, as in ,he grabs the public key of the original and then somehow uses it itself to MITM The whole thing.

If you were to verify the file MITM posted then the key signature would be different from the signature of the original.

The only way for MITM to have legitimately signed files is for MITM to use his own keypair for it.

He can't go half and half etc.

>>44198183
>The only way for MITM to have legitimately signed files is for MITM to use his own keypair for it.

And unless you know a way to tell the original apart from fakes... you can't be sure if it's the original or the fake.

That's the key ingredient.

If MITM generates a fake keypair to impersonate someone else, then he can only use that fake keypair to sign files with, or else his own signed files would fail to verify against the fake key.

But if everything checks out, then at that point only one thing has been established.

That whoever is signing the files has the same pubkey, etc.

If that is Mr. Original or MITM is up to you to verify.

GPG gives no indication about that except by looking at the key and seeing if trustworthy people have vouched for its legitimacy.

But that too is not 10000000000% reliable.

In short
GPG and GPG signed files are only good to show that the file is from the source it claims to be (the pubkey posted).

If the pubkey posted is actually owned by the person you want is a different story.

Does this help?

>>44198264
>If the pubkey posted is actually owned by the person you want is a different story.

In other words.

I could, right now, generate a key that says it's from
[email protected]
has his name
and his comment (whatever it may be)

then I could take that key to sign a file, which I post along with my public (notch impersonating) key.

you would then import this public key so you can actually verify the file I have signed and see if it matches up with the key you imported.

if it did, then you know that it came from me.

however, I am not Notch.
so if you were to ask me to tell you something you know that only Notch knows, then I would fail to verify that identity and that key should be marked as untrustworthy.

if I do know the details and you are 100% sure that I am indeed Notch after all, and my signed file matches the now verified key:
congrats, you just got a file from Notch, the real deal, etc.

the only difference this whole thing makes if I pass or fail your personal verification about whether I'm really Notch.

IF the signed files match the key I posted then that just means that I, who posted the key, and who may or may not be Notch, really signed this file with the key.

Nothing more, nothing less.

And I don't know if I could make this any simpler.

>>44198406
>then I could take that key to sign a file, which I post along with my public (notch impersonating) key.

Of course if you would already have Notchs key and verified it so you know it is him, and I would post a pubkey that impersonates him, then it would be trivial to expose me as a fake if I sign anything with it (and the actual key itself would be different as well, of course).

>>44198264
>If that is Mr. Original or MITM is up to you to verify.

And that can only really be done in person, if you knew the owner of the package beforehand.

>GPG and GPG signed files are only good to show that the file is from the source it claims to be (the pubkey posted).

"It claims to be", that is the problem.

>Does this help?
Well, it does help me understand, but it doesn't help me believe that you can be 100% safe.

Again if I was MITM'd this is what would happen:

I go to what I think is torproject.org, but I get connected to MITM.

I download what I believe is legit Tor, but is actually tampered Tor from MITM.

I also get the public keys, which I believe are from Tor project, but are actually from MITM.

I check them against Tor package I got, and it checks out because, again, the package was set up by the MITM.

I try to see if trustworthy people have vouched for it, but I get connected to MITM who can impersonate "trustworthy people", and claim all is legit.

I still don't believe it, so I contact the actual listed owner of the key to meet him in person, but I get connected with MITM and eventually I meet MITM, believing his the owner.

I know this is far-fetched, but it's not a legitimate concern as much as theorizing and me wanting to know how this all actually works.

But, if someone was specifically targeting me, and wanted to put more effort into it, this would be (a successful) way to go about it, right? Except if I new the actual owner of the package from way back and I met him in person.

>>44198406
Well, you beat me to it. I just typed all this shit for nothing...

>>44198580
>Well, it does help me understand, but it doesn't help me believe that you can be 100% safe.
You cannot be 100% safe.
Even in person, it could be someone wearing the face of the target and knowing everything about their past, etc.

But yeah, it's not possible to just intercept a signature and forge it into something else, well, it is possible but it would fail to check against your key, unless they person who is forging it up already uses that key, but then they wouldn't have to tamper with the signature, etc.

But yeah, in the end, it's the verifying the source that matters the most.
GPG and signature just show that the signed file really comes from a certain pubkey source, but doesn't say much more.

>>44198580
>I try to see if trustworthy people have vouched for it, but I get connected to MITM who can impersonate "trustworthy people", and claim all is legit.

This is not so easy, for example.

Since you could go and verify those 'trustworthy' people as well.

Sure, it'd be a hassle but it would help you work out if it's some MITM fucking with you or if it's the real deal.

>>44198652
>it's the verifying the source that matters the most.

How do you do that?

>>44198686
>How do you do that?
In any way you see fit.

Talk to them over the phone.
Meet them in person.
Analyze their DNA.
Get a copy of their birth certificate and official papers.
Ask god if this person really is the person whom god created to be.
Look at the key and see if it has been signed by people you trust (and this implies that you already have the keys of these people so MITM can't just pretend to be them)
Etc.

That's up to you, really.
Whatever you think gives you the most certainity.

>>44198733
>Ask god if this person really is the person whom god created to be.
What if they are impersonating God?

>>44198749
>What if they are impersonating God?
Ask them something from the bible or equivalent scripture.

Like...are you real?
If they answer "yes" then it really is God cause the bible says that God is real.

But yeah. It's the crux (heh) of the whole story.
Verifying the source of the key.

>>44198733
Okay, thanks for clearing it up!

Can you recommend me any books/wikis for laymen, where I can learn more about how encryption works and how to protect your privacy?

>>44198787
What if MITM wrote the Bible? The long con...

>>44198822
No problem, but no, I don't have any good resources per se.

Perhaps there are some CBT nuggets about it.
I'd be surprised if there weren't, and CBT nuggets are usally really good at explaining things.

>What if MITM wrote the Bible? The long con...
Sounds like what's actually going down if you ask me.

Or is it?!

That key still needs to be verified.

>>44198881
>Perhaps there are some CBT nuggets about it.
Just checked.
Doesn't seem like it, unless they are hidden in the security section, but not sure.

My own source was the man page and the internet.

>>44198881
>Perhaps there are some CBT nuggets about it.
I'll check it but I doubt it's for me, since:

>On-demand video training for IT pros.

>>44198917
>My own source was the man page and the internet.

That's what I though. Would be nice if there was some starters guide, but that'll do.

Thanks, faggots.

>>44199043
>On-demand video training for IT pros.
I think they're just saying that to make people feel better about themselves.

They do offer basic training videos about the most basic things, too, after all.

Like super baby level, like how to use ls, cd, and so on.

>Would be nice if there was some starters guide, but that'll do.

Well if it's guides on how to create keypairs, their details, their revocation keys and how to use them then you will find lots of those online.

Can't find the one I orginally used, though.

>>44199043
https://www.gnupg.org/gph/en/manual.html#INTRO

This guide works too, though.