Re: serialization formats [formerly: Curve p25519 Replacements for GnuPG?...]
Hi, I'm the author of pcp. Just wanted to note, that I'm not using plain base85 but Z85 (http://rfc.zeromq.org/spec:32) instead. It's fast and small. The reason is to have compatibility with ZeroMQ in the future. best regards, Tom PS: sorry for destroying the thread tree, I wasn't subscribed until now. -- PGP Key: https://www.daemon.de/txt/tom-pgp-pubkey.txt S/Mime Cert: https://www.daemon.de/txt/tom-smime-cert.pem Bitmessage: BM-2DAcYUx3xByfwbx2bYYxeXgq3zDscez8wC -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
On 2014-01-14 04:41, Thomas von Dein wrote:
Hi,
I'm the author of pcp. Just wanted to note, that I'm not using plain base85 but Z85 (http://rfc.zeromq.org/spec:32) instead. It's fast and small. The reason is to have compatibility with ZeroMQ in the future.
This specification does not address breaking the data into lines, nor a line checksum, nor the handling of impermissible characters (such as carriage return and line feed) Nor the recognition of string boundaries. Dangerously incomplete specification. Needs to be contained within a larger specification for handling the string.
On 2014-01-14, James A. Donald wrote:
This specification does not address breaking the data into lines, nor a line checksum, nor the handling of impermissible characters (such as carriage return and line feed)
In general, why does anybody do anything but binary formats in crypto, anymore? They just invite all sorts of padding trouble and what the hell not. If you have a clean proof, even against an oracle model, in something as beautiful as GF(2^8), why the *fuck* do you have to mess it up by translating to those very linefeeds and shit you usually really don't understand nor mostly can do right in the first place? Just goddamn dump the bits. Pretty much everything is 8-bit-clean nowadays. Nobody sends email anymore. TCP most _certainly_ is 8-bit-clean. Fucking dump it down the socket, guarded by a proper MAC. How difficult is that to comprehend, really? -- Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
participants (3)
-
James A. Donald -
Sampo Syreeni -
Thomas von Dein