During the last weeks I made lots of changes to the PCP code. Most of it was refactoring of internal stuff. First, I implemented a C Buffer "class", inspired by OpenSSH's buffer.c. I really like it. It can be used to incrementally fill a buffer, the buffer resizes automatically and makes boundary checks on every call to avoid buffer overflows. I can also directly put numbers of different sizes into it and multibyte numbers can be converted to big-endian automatically. The same prinziples can be used in the reverse, it's possible to read from a buffer little chunks. It remembers the last read offset and also supports host-endian conversion.

On top I wrote a C stream "class". This one is even nicer, since it can be used to read/write from/to files OR buffers. It behaves almost like the FILE interface, you can use ps_write() to put data out or ps_read() to fetch data in. That way I can do blockwise encryption on files and memory buffers. In fact, the encryption API uses those streams. But the latest addition to the stream class is even better: it can transparently encode to Z85 encoding. And in read-mode it can decode and determine automatically if the input is encoded. I'm not using it in the API yet, but the sample program already uses it and it works like a charm.

As you can see from the various links in this post, I also added some fairly amount of API documentation which is available here for online reading. It's generated using doxygen and I love it.

What else? I changed the sign and crypt mode of pcp, it signs the recipient list and a hash of the original content, and encrypts the signature. I re-factored some of the Z85 code to be more reliable and fault tolerant. I changed the native format of PCP public key exports. Public keys are now exported in RFC4880 (OpenPGP) format. While my exports are incompatible with OpenPGP (which is not intended anyway), the format is much more flexible than my old format. Previously I just dumped the pubkey C-structure to disk. While that worked well, it's completely impractical if I ever change that structure (which I did a lot so far). Now with the RFC4880 format, exported keys are indepentent from the internal structure, therefore I can change it as I wish without ever getting incompatible to old exports.

While I was at it, I also changed the export format of secret keys. While I don't use RFC4880 for this, I use at least a much more formalized format and not just a structure dump. Also, the whole export is now encrypted, not just the secret key blobs inside.

Last but not least, you can now export public keys in a couple of programming languages, such as a perl structure, or C code or YAML. That way an exported key can be used in small programs without the hassle of generating and maintaining keys. Just use PCP for key management.

As always latest source is on Github.

Update 2014-03-04:

I've got the last big change done, I removed -P and -S, now keys of any type are imported with -K. The new importer uses the Pcpstream decoder as well, so the last remaining part which isn't using it, is the clearsig reader. I also fixed more bugs in the decoder.

Update 2014-03-02:

While I was at it, I fixed a couple of other encoding related bugs, added unittests for it, enhanced the commandline a little and added a verbose key listing feature (someone on cypherpunks requested it). Usually a key listing looks like this:

pcp1 -l
Key ID               Type             Creation Time        Owner
0xB5B64D99AE73F3BE   primary secret   2014-03-02T23:14:23  Mallory 
0x629AFD2418EFA3BA   secret           2014-03-01T18:50:06  Alicia 
0x969D5931D7B409C6   valid public     2014-03-01T18:50:07  Bobby 
0x4EF5795E2874AD8D   valid public     2014-03-01T18:50:09  Bart 

Note the validity new flag for public keys.

Now, the new verbose listing:

pcp1 -L
Key ID               Type             Creation Time        Owner
0xB5B64D99AE73F3BE   primary secret   2014-03-02T23:14:23  Mallory 
    88b3a815 49c28236 7e6e3c31 17c286c5 7905c7a7 ec78911f 1fd76563 5688e4c0 
    encrypted: yes, serial: c940b8f0, version: 6
0x629AFD2418EFA3BA   secret           2014-03-01T18:50:06  Alicia alicia@local
076f002c 37b39ab5 cb0818b7 1fe33168 38b4d7d6 1b6e52c2 25229159 5405ec86
encrypted: yes, serial: 5386733f, version: 6
0x969D5931D7B409C6   valid public     2014-03-01T18:50:07  Bobby bobby@local
2d1efc28 ef294913 06a914be 986975d9 869d01e1 82ea026f a4c16c98 b6a2e2bb
signed: yes, serial: f7cb26b4, version: 6, signature fingerprint:
324fde54 3f6725ee a8c74f67 998e5b61 10a6f2db cdb2f282 1a689be2 3af1e514
0x4EF5795E2874AD8D   valid public     2014-03-01T18:50:09  Bart bart@local
9b660a1b a688d8fa 4a3b3a02 78b75363 70d01656 30045245 55d74944 f08bb5ab
signed: yes, serial: 1b4ed012, version: 6, signature fingerprint:
5449b8f4 9f0fe50e 3e46c1be e9225e26 aa1354bf 6bd105c3 147a9870 8a531161

Basically it displays the fingerprint of the keys, some flags and - if present - the key signature fingerprint. I store the signature anyway but didn’t use or display it yet.

Update 2014-03-02:

So, finally I reverted the tilde stuff successfully. Now, PCP uses hyphens again. While I was at it, I enhanced the decoder and parser a lot. It’s now more robust and parses the input linewise. Both the pcpstream decoder and the string decoder (z85_readstring()) now use the same framework. Previously they were independent from each other, so in fact I had two parsers. This was odd anyway so I generalized it.

The only remaining bad thing are clear signatures. They are parsed directly in ed.c and not by the stream decoder. I need to extend the stream decoder to be able to work on that stuff as well.

This Github commit was the last change to get into a stable state again. All unittests pass again. Thanks god (and my wife for her patience!)

Update 2014-02-28:

During the last days I made another large change, I changed the header markers for Z85 encoded data. Until now I had something like
----- BEGIN blah...-----
just as it's being used in PEM and elsewhere. This is no problem at all for small files like keys. But I wanted to have armored encryption as well, and there I fell heavily on my nose, including bleeding, crying and cursing of course.

The thing is, that the hyphen is a legitimate Z85 character and it may happen that ----- is legitimate Z85 encoded content. Proof:

$ perl -e 'foreach ((0xc6, 0x5a, 0x0b, 0x13)) { print chr($_) }' | pcp1 -z
-----

And since I'm reading input in streaming mode, it may happen that such a marker crosses block boundaries. So, I had to solve this. And my solution was quite genious or so I thought *g*. I just used the tilde character as marker which is not part of the Z85 characterset. One tilde starts a comment, another finishes it. Really easy. I had not much to change and it worked like a charm, even via block boundaries.

However, I spoke with Pieter about the issue and basically he told me, that my idea was bad (he said: "badly-designed parser"). Well. As of this writing the tilde-mode code is on github, but I already started to rewrite it. Again! Holy shit.

So in the next iteration (hopefully the last one, it's a boring business), I'll use hyphens again but read the streams in a totally different way. In fact if an input stream is considered Z85 encoded, it will be read linewise by the decoder. The decoder parses every line then and that way it's easily possible to detect headers, comments and footers. Once a Z85 block is complete, it will be decoded and put into the internal read cache. If there is something left on the line, it will be saved for the next iteration. So in fact, there are now 2 caches, one for decoded data (used by the caller) and one for undecoded data (kind of read ahead cache).

It's not done yet and I'm sure this stuff will steal me another couple days. Damn. However, at least it's currently in a state where it can parse and decode a complete stream. But I didn't try it with different blocksizes and I didn't even dare to run the unittests yet.

The new code isn't pushed to github so far, because yesterday I had a major problem with git. Thanks god I managed to solve it. "git merge", goddamnshit.

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 2014-02-06:

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

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.

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 2014-01-29:

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

Update 2014-01-29:

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 2014-01-20:

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 2014-01-20:

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 2014-01-17:

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.

Finally I can release version 0.1.5 of PCP. It's now really portable, it runs on AIX/power-pc (big-endian), FreeBSD, Linux and Windows (Cygwin). There's also now a C++ API and I fixed lots of bugs. Read the CHANGELOG for details.