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.

gpg concept

manpage: gpg.man.txt

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

or keys.gnupg.net / pgp.key-server.io (GPG default keyserver).

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)
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
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
pub   2048R/8BB44428 2017-06-08
uid                  maria <maria@local.com>
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
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 <maria@local.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 <maria@local.com>" 1 new signature
gpg: Total number processed: 1
gpg:         new signatures: 1

# make sure to always prepend 0x when you search for a key

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!