Auferstanden von den Toten

Vor vielen Monaten, eher einem halben Jahr, habe ich von einem Freund einen Kammdornwels übernommen. Er hat sein Becken abgeschafft, alle Fische abgegeben, nur ihn wollte niemand haben. Ich hatte ihn damals in mein Becken getan und seither nie wieder gesehen. Mir wurde zwar versichert, dass der sich selten blicken lässt und wenn, dann nur nachts. Aber ich habe ihn nie zu Gesicht bekommen.

Tatsächlich war ich felsenfest davon überzeugt, dass er gestorben ist. Vielleicht war er irgendwo eingeklemmt und ist verhungert oder es war ihm zu kalt. Tja. Bis gestern nacht.

Ich machte meine übliche Runde, kam am Becken vorbei und bekam einen Mordsschreck: da trieb sich irgendein Riesenvieh im Vordergrund herum. Taschenlampe geholt, nachgeschaut und siehe da: der olle Knurrwels! Unfassbar. Ich frage mich echt, wie der die letzten Monate überlebt hat.

Eigenartig ist, dass er ausgerechnet jetzt aufgetaucht ist. Am Mittwoch habe ich nämlich das Becken umgebaut. Unter anderem habe ich auch eine Wurzel entfernt. Vielleicht war er darunter eingeklemmt und ich hab ihn befreit. Oder er hat so eine Art Winterschlaf gemacht und ich hab ihn geweckt. Wer weiss :)

Hier ist er also: mein Agamyxis pectinifrons, Alter unbekannt, Name Erwin:

Bild: Erwin 1
Erwin 1 (Feb. 21, 2014, 4:11 p.m.)
[Tags: fische ] [Album: Aquarium ]
Bild: Erwin 2
Erwin 2 (Feb. 21, 2014, 4:12 p.m.)
[Tags: fische ] [Album: Aquarium ]
Bild: Erwin 3
Erwin 3 (Feb. 21, 2014, 4:12 p.m.)
[Tags: fische ] [Album: Aquarium ]
Bild: Erwin 4
Erwin 4 (Feb. 21, 2014, 4:12 p.m.)
[Tags: fische ] [Album: Aquarium ]
Bild: Erwin 5
Erwin 5 (Feb. 21, 2014, 4:12 p.m.)
[Tags: fische ] [Album: Aquarium ]
Bild: Erwin 6
Erwin 6 (Feb. 21, 2014, 4:12 p.m.)
[Tags: fische ] [Album: Aquarium ]
Bild: Erwin 7
Erwin 7 (Feb. 21, 2014, 4:12 p.m.)
[Tags: fische ] [Album: Aquarium ]

21.02.2014 16:11 CC0 Aquarium






Aquarium Umgebaut

Heute hab ich das Aquarium etwas umgebaut, eine Wurzel entfernt und diverse Pflanzen. Und gegärtnert. Nun haben die Elritzen hoffentlich genug Schwimmraum. Immerhin ist eine von ihnen schon in Paarungsfärbung (orange), man sieht sie auf den Bildern hier und da.

Bild: Aquarium Umbau 1
Aquarium Umbau 1 (Feb. 19, 2014, 7:51 p.m.)
[Tags: aquarium2013 ] [Album: Aquarium ]
Bild: Aquarium Umbau 1
Aquarium Umbau 1 (Feb. 19, 2014, 7:51 p.m.)
[Tags: aquarium2013 ] [Album: Aquarium ]
Bild: Aquarium Umbau 3
Aquarium Umbau 3 (Feb. 19, 2014, 7:51 p.m.)
[Tags: aquarium2013 ] [Album: Aquarium ]

19.02.2014 19:49 CC0 aquarium2013 Aquarium






Becken vom 08.02.2014

Frisch gegärtnert:

Bild: Becken vom 08.02.2014
Becken vom 08.02.2014 (Feb. 8, 2014, 5:52 p.m.)
[Tags: aquarium2013 ] [Album: Aquarium ]

08.02.2014 17:52 CC0 aquarium2013 becken Aquarium






pcp/pbp compatibility progress - Updated 06.02.2014 20:12

It's getting better and better. Not only do I have some very nice and secure sign+crypt functionality in PCP, but public key export and import from pcp to pbp and vice versa works now finally. From pbp issue#10:

PBP => PCP:

$ pbp -b . -x --self Tom > tom.pbp 
Passphrase for decrypting master key for Tom: 

$ pcp1 -V vx -P -I tom.pbp -b
key 0x61E05C2AA4803742 added to vx.

 $ pcp1 -V vx -l              
Key ID               Type      Creation Time        Owner
0x61E05C2AA4803742    public   2014-02-06T07:31:00  Tom <>

PCP => PBP:

$ pcp1 -V va -b -p -O alice.pbp   
Enter passphrase to decrypt your secret key for signing the export: 
public key exported in PBP format.

$ pbp -b . -X -i alice.pbp 
Success: imported public keys for Alice

$ pbp -b .  -l
invalid 9163 3781 9b14 ea5b 010b 7487 61fd dd46 Alice
valid 9275 5a5d 5375 bb49 d096 e0c5 1261 a575 Bob

Pure happyness!

One drawback does it have though: public key crypto doesn't work yet. I suspect the recipient list computing is incompatible since symetric crypto already works. At least pcp says that it cannot find a matching public key. And the other direction doesn't work too. But that's the smallest of all possible problems.


Update 06.02.2014 20:12:

And. Now. Finally.

# bob exports his pk
bobby@io: % pbp -x --self Bob > bob.pbp
Passphrase for decrypting master key for Bob: 

# alice exports her pk
alicia@io: % pcp -p -b -O alice.pbp
Enter passphrase to decrypt your secret key for signing the export: 
public key exported in PBP format.

# bob imports alice' pk
bobby@io: % pbp -X -i alice.pbp 
Success: imported public keys for Alicia

bobby@io: % pbp -l
valid b888 026a 38e2 cdf7 f0a6 6486 63a5 0fea Bob
invalid ed32 1935 0310 fe6f 35c6 b44d be6b 3ca8 Alicia   [1]


# alice imports bobs pk
alicia@io: % pcp -P -I bob.pbp -b
key 0x87358A0988953A67 added to ~/.pcpvault.

alicia@io: % pcp -l
Key ID               Type      Creation Time        Owner
0xB497AFF45654CD98   primary   2014-02-06T19:58:09  Alicia <>
0x87358A0988953A67    public   2014-02-06T18:58:02  bob <>

# bob encrypts to alice
bobby@io: % echo "HALLO ALICE, KNUTSCHI" > msg
bobby@io: % pbp -c -i msg -o encrypted -r Alicia -S Bob
Passphrase for decrypting encryption subkey for Bob:

# alice decrypts it
alicia@io: % pcp -d -I encrypted 
Enter passphrase to decrypt your secret key: 
HALLO ALICE, KNUTSCHI
Decrypted 22 bytes successfully

# other way around, alice encrypts to bob
alicia@io: % echo "ACH, SCHNUCKI" | pcp -e -O encrypted -r Bob
Enter passphrase to decrypt your secret key: 
Encrypted 164 bytes for:
bob <>

# and bob decrypts it
bobby@io: % pbp -d -i encrypted -S Bob
Passphrase for decrypting encryption subkey for Bob: 
ACH, SCHNUCKI
good message from Alicia


06.02.2014 19:46 CC0 crypto pcp privacy Source






Garnelen Fotos - Updated 05.02.2014 18:16

Heute sind mir zur Abwechslung mal zwei Garnelenfotos gelungen, die waren gerade am Zucchinifuttern. Irgendwie ist das echt schwierig, die scharf aufs Foto zu kriegen...

Bild: Mama mit Kind
Mama mit Kind (Feb. 5, 2014, 4:59 p.m.)
[Tags: ] [Album: Aquarium ]
Bild: Baby alleine
Baby alleine (Feb. 5, 2014, 4:59 p.m.)
[Tags: ] [Album: Aquarium ]
Bild: Und der ganze Haufen
Und der ganze Haufen (Feb. 5, 2014, 5:25 p.m.)
[Tags: ] [Album: Aquarium ]


Update 05.02.2014 18:16:

Und ein Video hab ich auch noch gemacht, da sieht man die komischerweise besser:


05.02.2014 16:58 CC0 aquarium2013 Aquarium






Heute gabs mal Pizza zur Abwechslung

Bild: Piiizza
Piiizza (Jan. 21, 2014, 10:39 p.m.)
[Tags: futter ] [Album: shots ]

21.01.2014 22:39 CC0 futter Geschwätz






Python CFFI Scheisse

Heute wollte ich mir pbp installieren, um im Zug mit dem pcp Umbau anzufangen. Tja, aber Stef verwendet CFFI für das C-Interface. Ich ich muss sagen, als alter Perlmacker ist mir noch nie etwas beschisseneres untergekommen, als dieses CFFI. Ich habe pysodium und pbp vorschriftsmässig installiert mit:

python setup.py build
sudo python setup.py install

Und weder beim Build, noch beim install kamen irgendwelche Fehlermeldungen. Was mich verwundert hat, da die meisten Sourcen heutzutage arg linuxlastig sind und /usr/local in deren Welt nicht vorkommt. Und dort ist die libsodium bei mir installiert.

Tja, und dann habe ich einfach mal das Kommando pbp ausgeführt. Und was kam da? Compilerfehler! Zur Laufzeit, NACHDEM ich alles installiert hatte! Ich hab bei Stef einen Bug eröffnet, aber ich befürchte, da wird er auch nix machen können. Ich hab dann ein wenig herumgegoogelt, und was steht da in der CFFI Doku?

[..]but so far require a C compiler at runtime. (We plan to improve with caching and a way to distribute the compiled code.)

WTF?!

Ich meine, sowas kann man doch nicht machen, dass der Enduser bereits installierte Module noch compilieren muss. Was da alles schiefgehen kann, sieht man ja an meinem Bug. Und als ob das nicht schon schlimm genug wäre, ignoriert CFFI irgendwelche übergebenen CFLAGS oder LDFLAGS, und zwar sowohl während dem Installieren, als auch zur Laufzeit.

So eine Scheisse. Sowas geht gar nicht.

Dann habe ich noch festgestellt, wenn ich pbp aufrufe und die ganzen Compilerfehler kommen, dass es danach im aktuellen Verzeichnis ein neues Unterverzeichnis gibt: build/bdist.freebsd-9.0-RELEASE-p3-amd64/egg/pysodium/__pycache__/. Selbst, wenn der runtime-Build funktioniert hätte, wenn ich dieses Verzeichnis löschen würde, würde CFFI es erneut erstellen und den ganzen Kram erneut compilieren.

Nee. Das ist umso bescheuerter, als es ja durchaus schon lange Methoden gibt, Python-Code mit binären Libraries zu verheiraten.


19.01.2014 12:08 CC0 kritik python Source






Es hat wieder eine Elritze erwischt

Seit vorgestern war wieder eine meiner Rainbow Shiner krank, anscheinend was mit der Schwimmblase. Sie ist schräg nach oben immer unter der Wasseroberfläche geschwommen. Irgendwie hab ich bei denen sowas alle paar Monate. Heute habe ich dann entdeckt, dass sie während sie so geschwächt war, anscheinend angefressen worden ist. Furchtbar, ich hab sie von ihrem Leiden erlöst.

Bild: Rainbow Shiner angefressen
Rainbow Shiner angefressen (Jan. 18, 2014, 2:13 p.m.)
[Tags: rainbowshiner ] [Album: Aquarium ]







pcp und pbp auf Cypherpunks - Updated 29.01.2014 19:29

Gwen Hastings hat mich in einem Bugreport für pcp auf eine Diskussion auf der Cypherpunks Mailingliste über pcp vs. pbp aufmerksam gemacht. Gut, das ist nicht die echte Cypherpunks Liste von anno dazumal, aber immerhin. Sieht so aus, als ob ich mich mit dem Autor von pbp (ein Python Commandline Tool, das das gleiche wie mein pcp tut, allerdings mit mehr Features wie es aussieht) über Schlüsselformate etc einigen muss. Denn die Leute haben Recht: lieber einigen wir uns gleich von Anfang an, als das es Wildwuchs gibt. Mir ist das auch aus einem anderen Grund mehr als recht: in Ermangelung an Vorarbeiten oder vorhandenen Lösungen auf die ich aufsetzen konnte (wobei Lösungen wie x509 und Konsorten nicht in Frage kommen, too bloated), musste ich mir im Grunde alles selber ausdenken. Da ich eher der pragmatische Typ bin, hab ich halt einfach drauflos gecoded. Ja, funktionieren tut das alles soweit, aber ob das alles gute Entscheidungen waren? God knows.

Insofern ist das gut, dass das jetzt mal von Dritten demontiert wird. Ich hab zwar schon etwas Muffe, dass ich Kloppe krieg, aber da muss ich wohl durch. Zur Not muss ich halt pcp umschreiben, was ja kein Problem ist, lange regelmässige Zugfahrten sei Dank.

Jedenfalls zeigt das, dass Interesse vorhanden ist, was mich schonmal sehr freut. Und dass die Entwicklung weitergeht. Wir werden die NSA schon ficken :)


Update 17.01.2014 18:03:

Nachdem ich mir nun reichlich Gedanken gemacht habe und mich auch nochmal mit stef privat darüber ausgetauscht habe, erstelle ich hier mal eine Liste der Dinge, die ich in PCP falsch gemacht habe und ändern muss (mehr als note-to-self gedacht):

  • Key Derivation: der secret key eines PCP Schlüssels ist ja verschlüsselt, dazu wird vom Benutzer ein Passwort abgefragt. Man sollte jedoch nicht direkt das Passowort zum Verschlüsseln verwenden, sondern daraus einen Verschlüsselungs-Key erzeugen, "Key Derivation" genannt. Da libsodium keine solche Funktion anbietet, habe ich selber eine erstellt, nur als Provisorium gedacht. Die Methode hatte ich u.a. auf der ZeroMQ Mailingliste besprochen (dort ging es um das Erzeugen von Schlüsseln für CurveCP) und wir waren uns einig, dass meine Methode halbwegs ok sei. Ich hatte dabei aus dem Passwort einen Hash erzeugt und aus diesem Hash wieder einen Hash und so weiter, insgesamt 128000 mal. Das erschwert Bruteforceangriffe.
    Nachdem sich herausgestellt hat, dass stef in pbp bereits scrypt verwendet, habe ich mich entschlossen, das nun auch zu tun. Ich habe die Sourcen des "scrypt" Dateiverschlüsselungstools aus den FreeBSD Ports in der Version 1.1.6 verwendet und 1:1 in pcp eingebaut, incl. autoconf Macros usw. Status: solved
  • Key-IDs. Yuriy hat mich auf der Mailingliste wie vorherzusehen war, tatsächlich sprichwörtlich "verkloppt" für einige meiner Entscheidungen, eine davon war die Verwendung von Key-IDs. Meine PCP Schlüssel haben ja eine ID (errechnet als 2facher Jen-Hash aus dem Secretkey), u.a. weil ich für die Schlüssel-Datenbank (der Vault) irgendeinen geeigneten Identifier brauchte. Key-IDs erschienen mir eine gute Wahl, zumal die bei PGP auch benutzt werden. Nun sind Key-IDs an sich nichts schlechtes, aber es ist schlecht, die Key-ID einer verschlüsselten Datei beizufügen, damit der Empfänger weiss, von wem die Datei kam. Also präzise das, was ich derzeit in PCP mache.
    Das muss ich ändern, und ich werde mich da an stef's pbp orientieren und statt dessen den Public Key des Absenders mitschicken. Das löst ausserdem gleich ein weiteres Problem: nämlich das des Schlüsselaustauschs. Bisher ist es bei PCP nämlich erforderlich, dass BEIDE Partner einer Kommunikation vorher ihre Schlüssel ausgetauscht haben müssen. Wenn ich aber den Public Key des Absenders in der verschlüsselten Datei mitschicke, muss dem Absender nur noch der Public Key des Empfängers bekannt sein. Also so, wie es derzeit auch bei PGP ist. Eine erhebliche Verbesserung. Status: solved (20.01.2014).
  • Nur long-term Keys in PCP. Ein weiterer Fehler, auf den mich sowohl Yuriy und stef aufmerksam gemacht haben, ist, dass ich in PCP den Main Secret Key des Absenders verwende. Gerade bei Curve25519 soll man aber nach Möglichkeit sogenannte single-use Keys verwenden. In pbp wird dazu beim Verschlüsseln einer Datei auf Absenderseite ein neues Schlüsselpaar erzeugt, mit dem Secret Key dieses Paars und dem bekannten Public Key des Empfängers wird dann verschlüsselt, der Public Key wird an das verschlüsselte Ergebnis gehängt (siehe oben). Gespeichert wird das Schlüsselpaar nicht. Da der Public Key, den der Empfänger zum Entschlüsseln braucht, mit beiliegt, ist das kein Problem. Der Empfänger braucht den Public Key dann auch nicht zu speichern. Allerdings müsste der zum Antworten dann immer noch den eigentlichen Public Key des Absenders haben, den dieser unabhängig davon veröffentlichen (oder mitschicken) müsste. Ich muss die Doku von pbp auch nochmal anschauen, ich meine, stef schickt bei pbp den auch gleich mit. Status: solved (20.01.2014).
  • Derived Keys Feature. Mein "Derived Key" Feature wird durch den Punkt oben obsolete. Das hab ich mir tatsächlich nur ausgedacht um es einem potentiellen Angreifer schwieriger zu machen. Wenn aber eine Hälfte der verwendeten Schlüssel dynamisch ist, ist das nicht mehr notwendig. Ich werde das Feature daher aus dem Code entfernen. Im Nachhinein betrachtet ist das eh besser. Das ist ziemlich kompliziert und schwer zu verstehen, so schwer, dass ich selbst meine eigene Doku studieren muss, um mich zu erinnern wie das geht. Also weg damit. Status: solved (20.01.2014).
  • Crypto in an online setting. Ein weiteres Problem, dass ich mit PCP habe, sind grosse Dateien. Derzeit lese ich die komplett in den Speicher und verschlüssele sie komplett. Auf dem PC normalerweise kein grosses Drama. Aber auf Mobil- oder Embeddedgeräten schon. Ich muss das also ändern und mit Buffern arbeiten. Stef hat 32 KB als maximale Buffergrösse vorgeschlagen, bzw verwendet die in pbp. Dem werde ich mich anschliessen (schon aus Gründen der Kompatibilität). Eine Datei wird also blockweise verschlüsselt und nicht in einem Rutsch. Und jeder Block wird wie eine eigene Nachricht behandelt. Status: solved (28.01.2014)

Es gibt ausserdem noch eine Reihe von Inkompatibilitäten zwischen pcp und pbp, einige davon werden sich in Wohlgefallen auflösen, wenn ich die oben aufgelisteten Designfehler behoben habe, übrig wäre dann noch:

  • Schlüsselexportformat. Das wird der schwierige Teil. PBP speichert derzeit keine Metadaten IM Schlüssel, sondern im Filesystem. Das mache ich völlig anders, bei PCP sind die Metadaten (Owner, Mail, ID, Checksumme, Seriennummer, Version, Erzeugungsdatum, etc) direkt IM Schlüssel enthalten. Das ist zwar im einzelnen praktisch, andererseits hat Stef's Lösung sowas nicht mitzuschicken viele Vorteile. Das werde ich irgendwie lösen müssen. Eine Variante wäre, bei exportieren Public Keys keine Metadaten anzuhängen. Status: solved (28.01.2014)
    Hier muss ich noch hinzufügen, dass ich mich insofern geirrt habe, als dass in PBP Keys doch einige Metadaten enthalten sind, anscheinend hat Stef das bereits geändert. Wie dem auch sei, ich kann die jetzt exportieren und importieren (public only).
  • Verschlüsselungsmethode/mehrere Empfänger. Wir machen beide in pbp und pcp im Grunde das gleiche, es ist aber unterschiedlich implementiert. Ich verwende in pcp einfach die NACL Funktion crypto_box() und gut ist. Diese Funktion erzeugt einen symetrischen Key, verschlüsselt damit (und mit einer Nonce) die Nachricht, verschlüsselt dann diesen Key mit dem public key des Empfängers und dem secret key des Absenders (curve25519) und hängt den an die Nachricht.
    Stef hingegen macht in pbp zwar das gleiche, aber er macht es zu Fuss und verwendet nicht crypto_box(). Dadurch ist er in der Lage, eine Nachricht für mehrere Empfänger zu verschlüsseln, weil er nur den symetrischen Key für jeden Empfänger neu verschlüsseln muss. Ich muss in pcp in diesem Fall für jeden Empfänger alles neu verschlüsseln.
    Damit einher geht auch eine Änderung des Formats einer verschlüsselten Datei, die nicht nur den Public Key des Absenders, sondern auch den Public Key des Empfängers enthält (soweit ich wie gesagt, die pbp Doku verstanden habe). Status: solved (24.01.2014)
  • ED25519 und Curve25519 Key getrennt erzeugen. Yuriy wies mich auf der Cypherpunksliste auf ein weiteres Problem hin: ich errechne derzeit den Verschlüsselungskey (Curve25519) aus dem Signaturkey (ED25519). In diesem speziellen Fall kann ich aber immerhin sagen, dass das nicht meine eigene Idee war (oder wie er es formulierte: "self invention of a square wheeled bicycle" *g*), sondern ein Vorschlag der libsodium Entwickler, die ich nämlich extra auf deren Mailingliste danach gefragt hatte. Nun, Yuriy meint, ich soll die beiden Keys getrennt erzeugen. Stef macht das in pbp übrigens auch so. Hm. Für die Kompatibilität zu pbp ist das zwar völlig egal, aber ich kann das leicht ändern. Das wären nur ein paar Zeilen. Status: solved (20.01.2014)
  • Encoding. Hier wirds blöd. pbp verwendet Base85 und pcp verwendet Z85. Letzteres ist eine Abwandlung von Base85, allerdings kein weltweiter Standard. Andererseits ist bei dem Thema hier im Moment sowieso auf Standards "geschissen", nichts davon ist Standard, was ja auch Absicht ist. Denn die Standards sind ja kompromittiert wie wir inzwischen wissen. Jedenfalls habe ich keine rechte Lust, in C einen Base85 de/en-coder zu schreiben. Ich tendiere eher dazu, einen Z85 Encoder in Python zu schreiben und dafür einen Pullrequest an Stef zu schicken *g*. Mal sehen. Über kurz oder lang müssen wir jedenfalls das gleiche Encoding und in den Binärdaten das gleiche Format verwenden, sonst wird das nix. Status: open.

Tja, klingt nach viel Arbeit, riecht nach viel Arbeit und ist viel Arbeit. Etwas ärgerlich, dass der überwiegende Teil davon bei mir liegt. Aber was muss ich mir auch irgendwelche Dinge ausdenken, ich Honk. Aber das gute ist, dass ich dabei viel lerne und darum geht es mir persönlich eigentlich auch nur: immer was neues lernen. Ne Menge anderer Leute hätten Yuriys Kritik vielleicht beleidigt aufgefasst. Aber ich werde lieber ruppig eines besseren belehrt als gar nicht, und darauf kommt es an.


Update 20.01.2014 00:07:

Einiges konnte ich heute im Zug angehen (siehe solved Marker oben). Als nächstes muss ich den Verschlüsselungs-Code aus src/ nach libpcp/ verschieben. Im Moment hab ich in libpcp zwar passende Wrapperfunktionen, die ganze Vorarbeit, I/O usw passiert aber in src/. Das ist schlecht, weil es dadurch nicht Teil der Library ist und insbesondere in der C++ API habe ich dann das Problem, das nochmal nachcoden zu müssen. Den Teil habe ich aber schon länger in der TODO Liste stehen, insofern alles cool.

Wenn ich die Sachen ausgelagert habe, und der ganze I/O (d.h. Lesen des Inputs, Ver-oder Ent-schlüsselung, Schreiben des Outputs) in je einer Funktion ist, kann ich den 23kb-Blockmode von Stef implementieren, mehrere Empfänger einbauen etc pp. Vorher macht das keinen Sinn. Aber: wenn ich DAS habe, brauche ich "nur" noch eine Import/Export-Funktion für PBP-Schlüssel und schon sind PCP und PBP kompatibel. 2-3 Tage schätze ich mal, werd ich brauchen.


Update 20.01.2014 00:11:

Nachtrag: noch ein Funfact: Hauptkritik von Yuryi war ja wie erwähnt, dass ich die Key-ID bei verschlüsselten Dateien mitschicke, was ich nun gefixt hab. Heute hab ich die Manpage entsprechend upgedated und was stand da?:

When using for encryption, the keyid will be added to the message so that the receiver knows who was the sender of the message (B)
. Oh Mann. Tatsächlich war mir das also offenbar schonmal durch den Sinn gegangen, dass das eventuell blöd ist, aber ich habs komplett vergessen!

Wird aber noch besser: tatsächlich war es sogar so, dass ich gar nicht die Key-ID rausgeschrieben habe, sondern einen Hash davon. Eigentlich hätte ich die Kritik von Yuryi also zumindest was das betrifft, sauber abschmettern können. Ich werde alt, soviel steht mal fest. Aber ist nun auch egal, das Feature ist jetzt eh weg und das Tool wird dadurch insgesamt benutzerfreundlicher (und zwar wesentlich!).


Update 29.01.2014 18:20:

Die wichtigsten Sachen wären soweit fertig. Ich mache jetzt blockweise Verschlüsselung, per Default im ECB Mode, per configure Parameter kann man aber auch auf CBC wechseln (--enable-cbc). Letzteres erscheint mir als die bessere Wahl, auch wenn die EBC Blöcke 32k gross sind. Für mehrere Empfänger verschlüsseln geht auch. Das Format sollte PBP kompatibel sein. Im Selfmode wird tatsächlich symetrische Verschlüsselung verwendet. Und man kann jetzt PBP Public Keys importieren oder exportieren.


Update 29.01.2014 19:29:

Huch, es gibt noch eine Twittermeldung über PCP: :)


14.01.2014 18:20 CC0 nsa pcp security Source






Ach, Ihr Blutsauger...

Bild: Rundfunkbeitrag für 2 Jahre, Leckt mich!
Rundfunkbeitrag für 2 Jahre, Leckt mich! (Jan. 11, 2014, 5:47 p.m.)
[Tags: ] [Album: Screencaps ]

11.01.2014 17:46 CC0 kritik Geschwätz