I want to understand
 

Let me begin by saying I am completely new to Linux entirely, I pick up pretty fast as long as something is broken down into laymen s terms for me.

I'm pretty self sufficient most of the time of figuring out how to do things on debian as I am new, but more and more I find myself asking, why?

What I mean by this is I can usually accomplish my goal by simple trouble shooting, reading the error, Google the problem, find a quick fix, ect.
However, I try not just to fix whatever the issue may be, but to understand what the issue actually was, what caused it.

This applies to all sorts of issues, for instance, I was trying to simply install Google chrome web-browser on my Debian 7 Stock installation.

So i text edited the sources file tried a simple: sudo apt-get update
When I received this in return:

Now Keep in mind I'm just starting to learn my way around the console with the basics mkdir rm cd touch etc

I was simply able to google the issue and fix it with the following.

Now the type of question I have that simple google won't clearly illustrate is: What is the public key? I obviously got an error because I needed it but why is it necessary?

I am new and I plan to stick around and learn as much as I can.

Hope to hear from anyone with a spare moment,

Love and respect.

-ADHDlinux

As you wish to learn I think the simple answer here is to open the file :)

You will notice on the second line:
What may not be obvious is that this is the program which will use this file (ie key). On the simple side, like most 'keys' this one unlocks something too :)

So search for gnupg both on your machine (ie see what apt-whatever tells you about it (or maybe dpkg I am not terribly familiar with Debian)) and google the main page to find out more about it.

Note that this is a warning and not an error so it shouldn't affect your ability to download the google package.
jdk

A public key is used to verify the authenticity of a file/archive. It basically means, that if you have the public key, you can compare a file that has been signed, to see if it matches the public key.

Basically, if google's repository for chrome were to be hacked into, and someone replaced the chrome archive with a malicious file... your package tools will notice that the signature doesn't match the public key and it would raise a flag saying "this looks suspicious" because it doesn't match.

The signer has a private key (which is kept private by the person that signs the files)
The signer generates a signature file which can be verified using the public key.



In this scenario:
Lets say you wanted to download an iso, ftp://ftp.slackware.com/pub/slackwar...re64-14.1-iso/ from this directory. In the directory there is a file ending in *.asc. This is the signature file, that can be used to verify the *.iso file.

You obtain the public key, and then you can compare that public key to the signature file. Which will verify if the *.iso is valid and genuinly signed by the slackware team.

It can be useful to filter out maliciously placed files.

See:
https://www.gnupg.org/gph/en/manual/x135.html
https://en.wikipedia.org/wiki/Public-key_cryptography

Thank you for all the answers! So very helpful!

So let me ask this, if this "Public (Authentication) Key" is used to basically keep an eye on things to make sure say, the repository wasn't compromised and replaced with some sort of a malicious file, does that mean there would be no way for an individual to download let's call it "ExampleFile" from we'll say "ExampleRepo" Decompile this "ExampleFile" by some means, obtain the key they used to sign the legit package, then compromise the repo and inject a copy of the legit key they've pulled from the original into a malicious file and re-upload this "MaliciousFile" to the now "CompromisedRepo"?

If that made sense.


I really do appreciate all the input!

Well I'm not an expert in cryptography but as far as I know keys are really hard to crack,so to obtain the key used to sign a package from the code could take many years.

Pictures are always easier to understand http://www.infosec.gov.hk/english/it..._signature.gif
:)

When you import a public key (like you did for the chrome repository using apt-get). That public key which is located on your computer won't change. It's simply used to verify the signature file that comes with a published file. Much like email in the example picture above. It's meerly used to prove that the contents of the file haven't been tampered with.

To be able to inject malware into a package protected with public key cryptography the attacker would need to hack two different servers, the server that hosts the file and the public key server. They can then replace the package with the malware and also switch the public key with their own which they used to sign the malware package.

This is rather difficult in practice because somebody is likely to notice unless the attacker is very good and very comprehensive in what they do. If they replace the public key and only one package, then the other files on the server will result in verify error. This means they would need to replace all the packages signed with that key on that server, but you could still detect it by checking another server for the file and signature.

It would be easier if the package were just hashed using say sha1 or md5. Then you'd just need to hack one server and replace the file and its hash.

As for directly computing the private key from the public key, it is considered to be a mathematically difficult problem even tho the keys are related. You shouldn't worry too much about this possibility, but if someone comes up with a mathematical shortcut, which is plausible, then it would take much less time. However, such a thing will likely make headline news as soon as anyone suspects it might be happening ... except maybe if the NSA gag orders them.

Also see:
http://it-beta.slashdot.org/story/14...velopers-found

Its not about 'cracking' them really,.. its about stealing those that are unused but valid. This happened to Microsoft a while back.

I see, so in all due technicality it is possible, but highly unlikely as the amount of work is simply too much unless you're that determined. Very good to know!

Has helped me to understand this much more in depth!

Normally, the public key used to verify the package content is already on the installation medium of your distro and does not change. So if you installed from a clean medium, all packages downloaded by the package manager from the distro's infrastructure will be verified with the correct public key, and it will be very hard for an attacker to spread malware (he needs to hack the private key, which should be guarded very good by infrastructure maintainers; or use brute-force, which can take several universe-ages with today's hardware)

However, since ADHLinux downloaded the public key himself, you are right here: The owner of the downloaded key is not verified, it could be a spoofed key. It would not take two independent hacks: The attacker could just sit in ADHDLinux' network connection and manipulate traffic to both the download location and the key server. (Don't be scared ADHDLinux, I'm just talking theoretical. We have no indication that you are hacked :) . And there is the https connection to google). To verify the connection between a key and its owner, one needs an additional secure channel to compare the key fingerprint. That's what key-signing parties are for, at least between single persons/small groups/small companies.