Curve p25519 Replacements for GnuPG?(x2 now) Re: Pretty Curved Privacy.. ECC Curve p25519 util(Bernstein approved curve)
Bill Stewart
bill.stewart at pobox.com
Sat Jan 11 13:11:20 PST 2014
At 10:27 PM 1/10/2014, nymble wrote:
>one of several possible text encodings
>Others might include:
>- base 29
>- base 59
>- base 4096 (for UTF8 channels)
The primary reasons for text encoding were that people wanted to
transmit data through channels that might modify content or had
limitations on the size and type of content, such as 7-bit ASCII,
special interpretations of control characters, especially \r, \n, \0,
\t, conversion to/from EBCDIC or other character sets, line length
limitations, case-folding, multiple space compaction, parity bits,
etc. A secondary goal is to support transcription by humans or
optical character readers that are likely to make mistakes on some
similar-looking characters, but that's much less common. A tertiary
goal is that some programmers like to "improve" programs or make them
"more efficient" by twiddling bits in ways that lead to software
bugs, security holes, and the wrong kinds of chaos and anarchy, and
yes I'm particularly including Phil Zimmerman and the standards
committees who designed ASN.1 and DNS. To give those guys some slack,
most of us started programming before the 8-bit byte was really
universal and saving bytes here and there was *really* *important*.*
The most common encodings out there encode most of the characters in
base-16 (or octal, for old DEC applications) or base-64 (uuencode and
MIME), with various wrappers around them to handle line-length
limitations and sometimes checksums. Sadly, base-85 didn't catch on
- it used 5 characters to hold 4 bytes, vs. base-64's 6 characters
for 4 bytes, but it was late to the game and required doing
multiplication and division instead of just bit-shifting.
I've never seen base-29 or base-59 encodings - is base-29 some
attempt to fit into 5-level Baudot coding now that the deaf community
have pretty much all moved off Model-28 TTY emulators to ASCII or
mobile phone texting?
Base-4096 in UTF-8 would be silly - it gets you 12 bits per
variable-width character, requiring at least two bytes, so you could
just as well use two bytes of base-64 and not risk munging by systems
that don't understand UTF-8.
(* My first programming environment had a printer with 132
48-character type bars and Model 026 keypunches doing Hollerith
cards, which could print 56 different characters; I don't think we
did any hacks using non-printer-supported punchcard fields and the
card sorter, but it was possible.)
More information about the cypherpunks
mailing list