News items for tag privacy - Koos van den Hout

Someone reported to me my PGP key was expired and whether I was still using it or I gave up on PGP/GPG.

I have an expiry date on my key, but I do update it from time to time when expiry nears. I now notice just doing a gpg --refresh doesn't update the expiry moment. The solution is to hard fetch the key. In the case of my home pgp key:

$ gpg --keyserver pgp.surf.nl --receive-keys 0x5BA9368BE6F334E4

This updates the expiry date(s) and the uids. If you have my key and it looks expired and/or still has an old e-mail address with kzdoos in it please do this now. Complete data at pgp.surf.nl: Search results for '0x5BA9368BE6F334E4' where you can see all the details including the revoked bits. Those revoked bits won't show up in normal use.

I know gpg and other pgp related software has to be designed to be really really secure up to the last bit, but some attention to user friendlyness could be a good idea if it's possible to confuse even experienced pgp users.

Ik was vandaag weer eens op de lokatie waar ik eerder tot de conclusie kwam Je draadloze microfoon is prima af te luisteren en dit keer heb ik die bewering gecontroleerd.

Niet eens met een scanner maar met een nog makkelijkere aanpak: een laptop met een rtl-sdr dongle er aan en gqrx er op.

De draadloze microfoons en de ontvangers op die lokatie zijn van Sennheiser, wat als voordeel heeft dat ze niet in kanalen denken maar dat de frequentie waar ze op staan gewoon op het display staat. Ik kon dus simpel aflezen van de ontvangers waar ik de microfoons moest 'zoeken'. In een testje kon ik inderdaad de draaggolf van de microfoon prima vinden na inschakelen en met een FM demodulator ook het geluid prima weergeven op de laptop.

Omdat dit een bijeenkomst was waar ook informatie besproken werd die niet vrij de wereld in mag was ik hier even alert op. Maar dankzij een toegevoegde ruimtemicrofoon aan het plafond werden de draadloze microfoons niet gebruikt tijdens de bespreking van gevoelige informatie. Na de besprekingen ben ik even aan de gang gegaan met de laptop en kon toen de ingeschakelde microfoon prima ontvangen.

Op zich is er niets mis met draadloze microfoons, maar er zijn dus situaties te bedenken waarin je denkt dat je stemgeluid alleen binnen een beperkte ruimte versterkt wordt maar wat er net buiten misschien ook opgevangen wordt.

For ages the whole 'right to be forgotten' issue was something happening to other people for me. The worst I do on my website is name spammers that keep sending me unsollicited e-mail.

This changed when I started playing with old files from BBS Koos z'n Doos including old BBS lists.

A few years after I started putting these on-line I received a request to remove a name from the lists. This person advertised running a 'hardcore sex' BBS in the 1990s. But in 2013 the rather unique name of this person showed up with a decent company and in this BBS list.

I could imagine that this person had no idea in the 1990s what someone might do years later with that information. At the same time it felt bad to 'change history'. Those were original files, it felt bad to change them. But after consideration I changed the name to spaces.

I also received notice from the google webmaster program that some search results are hidden on bbs.idefix.net. I have no idea which ones or what names I should mask.

The whole 'right to be forgotten' is a typical 'shades of gray' subject.

I was plagued by thunderbird/enigmail in one installation not wanting to send PGP-encrypted messages. It took me a while to debug because I seemed to be the first one to come across it. The error messages are not very helpful with a lot of SIGEXPIRED in them followed by a KEYEXPIRED. I found someone with probably the same problem at Enigmail stopped working: KEYEXPIRED/SIGEXPIRED - Super User but no usable answer at that time.

Searching further found me [Enigmail] enigmail won't let me encrypt messages anymore which does show another problem with old keys in the further thread. I started removing old keys showing with '00 00 00' fingerprints until I found my old 'home' key in the ring (0x2C663B5DF0D7C263). After that the error message changed to the key being unavailable. I dug through ~/.gnupgp/gpg.conf looking for mentions, and found:

#default-key F0D7C263

already disabled, and:

encrypt-to F0D7C263

when I changed that last one to a newer and better fitting key the problem was solved. There was a mention of F0D7C263 at the end of the enigmail error message but it was hard to draw conclusions about what it was doing there.

So as usual: good encryption is hard. And good error messages are hard too. I added a suggestion to the superuser.com message so others may spend less time debugging this problem.

In een artikel in de Volkskrant vandaag KPN: introductie 5G bemoeilijkt door inlichtingendiensten - Volkskrant met daarin:

Het ministerie van Economische Zaken (EZ) biedt telecombedrijven in een recente beleidsnota aan andere frequentiebanden te veilen, omdat het voor de 3500 MHz-band vastzit aan een contract met het ministerie van Defensie tot aan 2026. De satellieten van de veiligheidsdiensten in het Friese Burum communiceren al jaren via deze hoge frequentie.

Volgens mij is dat helemaal niet "communiceren" maar alleen maar heel erg goed luisteren. In een eerdere zaak rond het gebruik van 3500 MHz kwam de nationale veiligheid ook voorbij, Enige wimax-provider in Nederland stopt ermee - Tweakers met daarin:

De reden voor het stoppen is dat Aerea zijn netwerk niet naar de noordelijke helft van Nederland mocht uitbreiden. Defensie wilde dat niet, omdat de 3,5GHz-frequentie het satellietgrondstation Station12, dat in handen is van Defensie, zou storen.

Met wat redeneren en nazoeken is wel te bedenken waar defensie/aivd/mivd zo graag naar wil luisteren: mobiele communicatie satellieten die in dat frequentiegebied signaal naar de aarde zenden.

Van tijd tot tijd lezen we verhalen over hoe vanuit Burum satelliet telefonie wordt afgeluisterd, zoals bijvoorbeeld Data uit Burum leiden naar piraten en terroristen - nrc.nl. Een beetje uitzoeken levert op dat onder andere de diverse Paksat satellieten zoals Paksat-1 - Wikipedia English die allerlei communicatiediensten leveren op de C-band op frequenties vanaf 3500 MHz. Waaronder satelliet-telefonie. En Nederland ligt aan de rand van het gebied waar deze signalen nog (zwak) te ontvangen zijn: Paksat-1R coverage map - Satbeams.

Mijn conclusie is dat de 'communicatie' waar het over gaat het afluisteren van de downlink communicatie van onder andere de Paksat-1R is.

In eerdere berichtgeving over de inval bij Ennetcom moest ik wel heel goed luisteren om niet de conclusie te trekken dat PGP 'alleen' gebruikt wordt door criminelen, NOS Journaal 20:00 19 april 2016, Paniek in onderwereld door gekraakte telefoons - EenVandaag.

Maar vandaag viel me op in artikel Politie krijgt toegang tot versleutelde communicatie criminelen - nos.nl dat er een paragraaf staat:

PGP is een veelgebruikte methode om veilig te communiceren en wordt niet alleen door criminelen maar ook door bijvoorbeeld journalisten en klokkenluiders gebruikt. Bij PGP worden berichten door elkaar gehusseld, zodat ze alleen leesbaar zijn voor mensen met een bepaalde encryptiesleutel.

Hier kan ook aan toegevoegd worden dat computerbeveiligers graag PGP gebruiken om hun berichten te ondertekenen en/of te versleutelen.

Uit de bijbehorende beslissing van de Canadese rechter op het internationale rechtshulpverzoek (Engelstalig) blijkt wel dat er helemaal geen lek in PGP is gevonden maar dat Ennetcom niet zo heel goed was in cryptobeheer:

In this case, the Dutch authorities discovered that the Ennetcom PGP BlackBerry devices were only able to communicate via PGP encrypted e-mail with other Ennetcom PGP BlackBerry devices connected to the same Ennetcom network. The Dutch authorities also discovered that the “keys” for the PGP encryption system were generated by the server, rather than by the device. As a result, the Dutch authorities came to believe that the keys to decrypt the PGP encrypted information, on the Ennetcom PGP BlackBerry devices, are stored on Ennetcom’s BlackBerry Enterprise Servers.

Vandaag was ik op een plek waar regelmatig draadloze microfoons gebruikt worden bij presentaties en/of grote vergaderingen. Er was recent een probleem waarbij geluid van andere gebruikers van het gebouw te horen was op de geluidsinstallatie, en dat bleek na wat zoeken ontvangst van de "verkeerde" microfoons te zijn.

Er ging toen ook een lichtje op dat draadloze microfoons prima af te luisteren zijn, wat in deze omgeving niet altijd een prettig idee is. Met een scanner die wide-fm en een groot bereik aan UHF frequenties aan kan is het prima mogelijk naar analoge "Program Management and Special Events" (PMSE) microfoons te luisteren.

The whole news about the "Evil32" attack on PGP keys made me have a long look at the key I used at home for my private e-mail, which was already almost 18 years old. Opinions about the best use of PGP have changed, risks have changed. So I followed some advice from Creating the perfect GPG keypair - Alex Cabal although 'perfect' is a bit overdone. I added the subkey for normal use, added a picture and cross-signed the new key with the old key. But in the end, the new key for my private e-mail addresses is:

pub   4096R/0x5BA9368BE6F334E4 2016-09-05 [expires: 2021-09-04]
      Key fingerprint = 979B CF89 EBBF 9AC9 6A14  F56A 5BA9 368B E6F3 34E4
uid                            Koos van den Hout <koos@kzdoos.xs4all.nl>
uid                            Koos van den Hout (http://idefix.net/) <koos+website@idefix.net>
uid                            [jpeg image of size 11615]
uid                            Koos van den Hout <koos@idefix.net>
sub   4096R/0x308216DA78517E3D 2016-09-05 [expires: 2021-09-04]
sub   4096R/0x3B17C9ABE4A3C916 2016-09-05 [expires: 2021-09-04]

The key is now available via my PGP page and via the keyservers: 0x5BA9368BE6F334E4 on the keyservers

Now the next step is to start collecting signatures.

For a while I have been using the gnupg.vim plugin but I noticed recently after changing my gnupg configuration to show long IDs that this plugin had problems. I searched and found a new version of the plugin at vim-gnupg/gnupg.vim at master · jamessan/vim-gnupg which does not have this problem.

So now I can simply keep text information in encrypted files and I need to type the passphrase every time I want to edit the file.

The easiest way to create an encrypted file to use with this plugin is create an empty file, encrypt that file from the command line and then edit it with the plugin:

$ touch datafile.txt
$ gpg -e datafile.txt
You did not specify a user ID. (you may use "-r")

Current recipients:
4096g/0xCC166EB91F480E9A 2011-01-11 "Koos van den Hout <koos@kzdoos.xs4all.nl>"

Enter the user ID.  End with an empty line: 
$ ls -l datafile.txt*
-rw-r--r-- 1 koos users    0 Sep  4 20:49 datafile.txt
-rw-r--r-- 1 koos users 1114 Sep  4 20:50 datafile.txt.gpg
$ wipe datafile.txt
Okay to WIPE 1 regular file ? (Yes/No) Yes
Operation finished.                                                           
1 file wiped and 0 special files ignored in 0 directories, 0 symlinks removed but not followed, 0 errors occured.

Now editing the file with vim datafile.txt.gpg goes through decrypting the file before starting the editing session and saves it encrypted when done.

De slimme meter die meer dan een maand geleden ons huis in kwam wordt nu constant uitgelezen en de resulterende gegevens worden opgeslagen in rrdtool databases van het electriciteits- en gas gebruik.

Uitlezen van een seriele poort vanuit Perl bleek niet makkelijk stabiel te krijgen te zijn. Uiteindelijk heb ik maar een oplossing gekozen/geleend van iemand anders: een stuk python wat cu aanroept: P1/P1-python-cu.py at master · sanderjo/P1. Dit script zou nog iets robuuster zijn als het de CRC controleert, maar dat is dan een wens voor een toekomstige versie.

Vervolgens sla ik de output van dit script op in /var/run/telemetry/smartmeteroutput. De keuze voor /var/run is omdat ik niet elke vijf minuten op de SD kaart van de raspberry wil schrijven. Ik heb dus ook /etc/rc.local aangepast om een /var/run/telemetry met als eigenaar user telemetry te maken, er worden daar meer meetgegevens neergezet voor verdere verwerking in statistieken. Het telemetry concept wat ik gebruik is het verzamelen in ASCII leesbare vorm van meetgegevens op systemen waarna deze opgehaald kunnen worden door een verzamelaar die ze gaat importeren in rrdtool databases (of andere verzamelingen). Omdat de verbinding tussen het te monitoren systeem en de verzamelaar als onbetrouwbaar gezien wordt (sommige systemen waarvan ik meetgegevens verzamel zitten achter een hikkende wifi verbinding) worden de meetgegevens lokaal opgeslagen met een tijdsaanduiding in de bestandsnaam en worden ze in rrdtool geimporteerd met deze tijdsaanduiding.

Het script wat de meetgegevens van de slimme meter verwerkt moet er tegen kunnen dat er soms velden ontbreken. Ik heb er voor gekozen uiteindelijk de dag- en nacht tellerstanden afgenomen en teruggeleverd (meetwaardes 1.8.1, 1.8.2, 2.8.1 en 2.8.2 in de Dutch smart meter standard) als 'verplicht' te tellen en de overige meetwaardes als 'optioneel'.

Uiteindelijk komen er dan mooie grafieken uit. De conclusie die ik eerder trok dat uit energie meetwaarden per kwartier prima af te leiden is wat bewoners doen is nog steeds valide. Uit grafieken over langere termijn is ook keurig af te zien wanneer we op vakantie waren.