Curve p25519 Replacements for GnuPG?(x2 now) Re: Pretty Curved Privacy.. ECC Curve p25519 util(Bernstein approved curve)

nymble nymble at gmail.com
Sun Jan 12 12:51:01 PST 2014


On Jan 11, 2014, at 8:02 AM, Cathal Garvey <cathalgarvey at cathalgarvey.me> wrote:

>> - base 4096 (for UTF8 channels)
> 
> I may reveal some crippling ignorance, but:
No … but it depends whats being counted.
...
> If we assume it's 3, and further assume that, after declaring that the
> following 3 bytes are an extension, that any arbitrary binary sequence
> will be interpreted as a visible, copy/pasteable character, then you're
> looking at a length penalty to encode arbitrary data of 33%. For every
> three bytes, you're escaping them to random characters by prefixing with
> another byte.

Twitter limits transmissions to 140 UTF8 characters. 
More than 140 binary characters can be encoded into 140 UTF
8 characters.

In any UTF8 capabile browser/mail/whatever - the apparent
length of a binary string will appear shorter even though the
underlying bytes are longer.

That said … such encoding tricks (base4096 or the like) might 
be better saved for encrypted content in Twiiter or other
UTF8 limited channels.

Public key representation would need to be consistent over
other ASCII limited channels.



> 
> Yes, it's more nuanced than that; you can factor in the ascii set and
> use that where possible, only escaping binary values outside the ascii
> set, but one way or another you're adding length to the binary string by
> messing with it, with the aim being a character-representable set of
> binary data that can be copy/pasted safely and passed through diverse
> transports.
> 
> So the question is what's more important; ability to transport strings
> of data without a significant length penalty, ability to transport
> strings of arbitrary data without affecting the transport, or ability to
> copy/paste (a subset of "transport" I guess).
> 
> Given these, my personal feeling is that if your concern is
> transport-related, which implies that you can't control the transport,
> then stick with base64. If your concern is length, then I don't feel
> UTF8 will offer a significant advantage, and you're much better off
> using something like length-prefixing like bencoding does it. If your
> concern is copy-pasteability, then base58 works and probably is no worse
> than base-utf8, while being significantly easier to implement in code.
> 
> Spurious rant over.
> 
> * Take for example the way early email was sent, where headers were
> specified and then the server awaited the body of the message, the end
> of which was indicated by what amounts to a string of characters; a
> newline, a period, and another newline. Easily injected by accident or
> design, along with other commands.
> 
> On 11/01/14 06:27, nymble wrote:
>> 
>> consistent key formats are critical, need to converge on:
>> - endianness
>> - coordinate representation x, x&y, x and sign …
>> or bits to show which of these …. perhaps borrow ANSI method
>> - hint / indication of cipher suite / curve 
>> - text encoding of binary format (ascii)
>> - text encoding of binary format (utf8)
>> - human readable format
>> 
>>> ecc public key curve p25519(pcp 0.15)
>> leaking crypto suite
>> key should be usable in other contexts besides pcp 0.15
>> 
>> 
>>> 1l0$WoM5C8z=yeZG7?$]f^Uu8.g>4rf#t^6mfW9(rr910
>> one of several possible text encodings
>> Others might include:
>> - base 29 
>> - base 59
>> - base 4096 (for UTF8 channels)
>> 
>> 
>> 
> <0x988B9099.asc>





More information about the cypherpunks mailing list