while gpg is very likely sound and solid encryption – what is far more likely to be compromised is YOUR HARDWARE – every network card – wifi card – usb UMTS G3 modem – PCI-Card – contains enough RAM and CPU to spy on you – hence the struggle with closed-source drivers.
Qualcomm but also Cisco are all US based manufacturers known to implement backdoors ON PURPSE probably for agencies to spy on you – the citizen – that they are so afraid of.
“We are also having tough times with GPS: all the GPS chips found in the Android phones we support implement a secret and non-documented protocol that we just cannot figure out.” (src)
it is called: is it a bug or a feature?
deliberate security holes – now also in the Intel Management Engine
We’ve written regularly, and sadly fairly frequently, about security holes in SoHo routers – holes that in many cases do not instil much confidence at all.
Some of these holes were simple bugs; even more alarmingly, others weren’t bugs, but deliberately-programmed security flaws.
For example, we’ve had:
- A remote code execution hole in Cisco devices allowing a cunningly crafted web request to take over your router.
- A Linksys bug allowing an external website to change the router’s password, and to enable login access over the internet.
- “Joel’s Backdoor” in D-Link routers, where a simple change in the User-Agent string in your browser would bypass the login screen.
- Sercomm’s undocumented ScMM backdoor interface that allowed you to bypass not just the login screen but the admin web pages too.
- Sercomm’s patch for the ScMM backdoor, implemented by hiding the backdoor behind a new backdoor.
same/similar to ssh concept – there is a public and a private key – the public key goes public – the private key stays with you – the user.
you do not have to – but could wear it like a neckless 😀
during key-generation gpg will ask you for your e-mail, because gpg is also used to send encrypted mail. (check out my tutorial howto on that topic)
for easier access of your public key – people (me) will search on a keyserver like pool.sks-keyservers.net
It does not matter what key-server you use – keyservers are supposed to sync between each other.
for your key – download it – before trying to send you an encrypted mail.
it will also ask you to do some „random work“ – well what is that? 😀
in order to make it hard to guess your private key and therefore bruteforce decrypt your files and messages – it is important to have some source of randomness.
in this case – what is more random than the user in front of a pc 😀
or what the user will do with that pc – you could open up firefox and surf the web.
if that is not enough entropy search the harddisk with find / -iname *filename* – or – works fast and interesting concept hardware entropy deamon (can not say anything about it’s quality) – install this program – apt-get install haveged; # (more on haveged scroll to bottom)
gpg --gen-key; # generate a new key for the currently logged-in user # key will be stored in ~/.gnupg gpg --list-key; # show my public-key file and all other imported keys (currently none) /home/user/.gnupg/pubring.gpg ----------------------------- pub 4096R/02BAD5D2 2017-06-08 uid userrr <user@debian8> sub 4096R/E84C122F 2017-06-08 gpg --list-secret-key; # list where private key is stored /home/user/.gnupg/secring.gpg ----------------------------- sec 4096R/02BAD5D2 2017-06-08 uid userrr <user@debian8> ssb 4096R/E84C122F 2017-06-08 gpg --export --output /tmp/user user; # export the key to file # now if you switch over / login as different user maria@Debian8:~$ gpg --import /tmp/user; # import key from /tmp/user gpg: key 02BAD5D2: public key "userrr <user@debian8>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg --list-key; # now also showing user's key /home/maria/.gnupg/pubring.gpg ------------------------------ pub 2048R/8BB44428 2017-06-08 uid maria <firstname.lastname@example.org> sub 2048R/1F894FD4 2017-06-08 pub 4096R/02BAD5D2 2017-06-08 uid userrr <user@debian8> sub 4096R/E84C122F 2017-06-08 vim file1; # create a test-file for encryption maria@Debian8:~$ gpg --encrypt -r userrr file1; # encrypt the file gpg: E84C122F: There is no assurance this key belongs to the named user pub 4096R/E84C122F 2017-06-08 userrr <user@debian8> Primary key fingerprint: A29F 8173 2C5A C2E3 84AA 5ECF 9248 B428 02BA D5D2 Subkey fingerprint: 46E2 96BD 9A30 983D 74C6 5D58 EA9A 3380 E84C 122F It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y maria@Debian8:~$ ll total 8.0K -rw-r--r-- 1 maria maria 74 Jun 8 10:59 file1 -rw-r--r-- 1 maria maria 664 Jun 8 10:59 file1.gpg <- newly created encrypted file cp file1.gpg /tmp/; # copy encrypted message to /tmp so user can access it # now switch back to first user "user" cp /tmp/file1.gpg /home/user/; # copy encrypted file into your home directory user@Debian8:~$ gpg file1.gpg; # decrypt the file You need a passphrase to unlock the secret key for user: "userrr <user@debian8>" 4096-bit RSA key, ID E84C122F, created 2017-06-08 (main key ID 02BAD5D2) gpg: encrypted with 4096-bit RSA key, ID E84C122F, created 2017-06-08 "userrr <user@debian8>" user@Debian8:~$ ll|grep file1 -rw-r--r-- 1 user user 74 Jun 8 11:03 file1 <- decrypted -rw-r--r-- 1 user user 664 Jun 8 11:02 file1.gpg gpg --gen-revoke userrr > revoke.txt; # make your key invalid - because you forgot your laptop in a taxi sec 4096R/02BAD5D2 2017-06-08 userrr <user@debian8> Create a revocation certificate for this key? (y/N) y Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision? 1 Enter an optional description; end it with an empty line: > fucked up > Reason for revocation: Key has been compromised fucked up Is this okay? (y/N) y You need a passphrase to unlock the secret key for user: "userrr <user@debian8>" 4096-bit RSA key, ID 02BAD5D2, created 2017-06-08 ASCII armored output forced. Revocation certificate created. Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others! user@Debian8:~$ gpg --import revoke.txt gpg: key 02BAD5D2: "userrr <user@debian8>" revocation certificate imported gpg: Total number processed: 1 gpg: new key revocations: 1 gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u user@Debian8:~$ gpg --list-key /home/user/.gnupg/pubring.gpg ----------------------------- pub 4096R/02BAD5D2 2017-06-08 [revoked: 2017-06-08] uid userrr <user@debian8> ### to upload a key to keyserver you either need to prepend 0x or need to use the long-key-id
gpg --keyid-format LONG -k 0x8BB44428 pub 2048R/6768022A8BB44428 2017-06-08 uid maria <email@example.com> sub 2048R/EA10BB8C1F894FD4 2017-06-08 maria@Debian8:~$ gpg --send-keys 0x6768022A8BB44428; # upload key with ID to server keys.gnupg.net
gpg: sending key 8BB44428 to hkp server keys.gnupg.net gpg --recv-keys 0x6768022A8BB44428; # to download the key again gpg: requesting key 8BB44428 from hkp server keys.gnupg.net gpg: key 8BB44428: "maria <firstname.lastname@example.org>" 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 # make sure to always prepend 0x when you search for a key https://pgp.key-server.io/pks/lookup?search=0x6768022A8BB44428&fingerprint=on&op=vindex
about HAVEGE entropy algorithm
haveged is a userspace entropy daemon which is not dependent upon the standard mechanisms for harvesting randomness for the system entropy pool. This is important in systems with high entropy needs or limited user interaction (e.g. headless servers).
haveged uses HAVEGE (HArdware Volatile Entropy Gathering and Expansion) to maintain a 1M pool of random bytes used to fill /dev/random whenever the supply of random bits in dev/random falls below the low water mark of the device.
More information about HAVEGE is available at http://www.irisa.fr/caps/projects/hipsor/
„HAVEGE combines on-the-fly hardware volatile entropy gathering with pseudo-random number generation. The internal state of HAVEGE includes thousands of internal volatile hardware states and is merely unmonitorable. Therefore HAVEGE features a very high security level.“
Yeah! Rock On!