Re: Looking for Base32Encoder/Decoder classes
Wei Dai
> If no-one has done one, any pointers on how best to write it? I've
> had a good look at HexEncoder and Base64Encoder and their
> superclasses and helpers, but I'm new to this framework and I suspect
> there are requirements on the class interface that I don't know
> about. Basically, I don't feel qualified to attempt a Base32Encoder
> and Base32Decoder before talking to you all.
All you have to do is make copies of hex.h and hex.cpp, and change the
class names and some of the constants that get passed to BaseN_Encoder and
BaseN_Decoder as parameters. The real work is done in BaseN_Encoder and
BaseN_Decoder, which work for any N between 2 and 128 that is a power of
2.
Richard Buckle
>All you have to do is make copies of hex.h and hex.cpp, and change the
>class names and some of the constants that get passed to BaseN_Encoder and
>BaseN_Decoder as parameters. The real work is done in BaseN_Encoder and
>BaseN_Decoder, which work for any N between 2 and 128 that is a power of
>2.
Thanks, I'll try that and submit my attempt for review.
Richard.
frank.p...@autodesk.com
Hello,
Well, a base32 implementation was submitted by someone over a year ago, for Crypto4.2. Unfortunately, it appears there are a few variations on the encoding. The author chose one for reasons he cites.
I'm currently using Crypto++4.2 plus this particular code in production, and it's working well.
I guess I'm requesting that this same encoding be used in 5.0, or else I will have to add a special one when I finally upgrade. Note that it uses lower case, and no padding.
Of course, this code doesn't use basecode.h, which any new code should as Wei said.
Thanks,
Frank
-----Original Message-----
From: Patrick Oscar Boykin [mailto:boy...@pobox.com]
Sent: Sunday, November 11, 2001 8:52 AM
To: cryptopp...@lists.sourceforge.net
Subject: [Cryptopp-develop] base32 encoding for cryptopp (code attached).
I have implemented a base32 encoder/decoder for Crypto++ (which is a pretty simple modification of Wei's base64 code).
I implemented the base32 representation found here (in section 4)
http://www.ietf.org/internet-drafts/draft-ietf-idn-dude-02.txt:
The details of the encoding are at the end of this message:
There are three or so base32 encodings, however the one I chose to implement has a few things going for it:
1) it is used in the proposal for UTF encoded domain names.
2) it is optimized against human transcription errors (it is case insensitive and 0,1,O,l are not used to avoid errors).
3) there is no padding "=" which only wastes characters and provides no additional information.
Why do you care??????
base32 encoded hashes are easier for humans to write down without errors than base64, yet take less space than base16 (hex).
These could be used for verification over a telephone, as parts of URL's, etc.... any place where a human might wind up doing some viewing, typing etc.... Base32 would be better than base64 there.
It would not be better for anything that a human would never see or manipulate (such as an email attachment, or a long file).
Note that base32 encoded data is (8/5) times as large as the original (since only 5 bits are stored in each byte).
I have tested this out reasonably thouroughly on Linux (but I can't imagine it being any different anywhere else).
Wei: I hope you will include this code in your next release of Crypto++.
P. Oscar Boykin.
=================================================================
"a" = 0 = 0x00 = 00000 "s" = 16 = 0x10 = 10000
"b" = 1 = 0x01 = 00001 "t" = 17 = 0x11 = 10001
"c" = 2 = 0x02 = 00010 "u" = 18 = 0x12 = 10010
"d" = 3 = 0x03 = 00011 "v" = 19 = 0x13 = 10011
"e" = 4 = 0x04 = 00100 "w" = 20 = 0x14 = 10100
"f" = 5 = 0x05 = 00101 "x" = 21 = 0x15 = 10101
"g" = 6 = 0x06 = 00110 "y" = 22 = 0x16 = 10110
"h" = 7 = 0x07 = 00111 "z" = 23 = 0x17 = 10111
"i" = 8 = 0x08 = 01000 "2" = 24 = 0x18 = 11000
"j" = 9 = 0x09 = 01001 "3" = 25 = 0x19 = 11001
"k" = 10 = 0x0A = 01010 "4" = 26 = 0x1A = 11010
"m" = 11 = 0x0B = 01011 "5" = 27 = 0x1B = 11011
"n" = 12 = 0x0C = 01100 "6" = 28 = 0x1C = 11100
"p" = 13 = 0x0D = 01101 "7" = 29 = 0x1D = 11101
"q" = 14 = 0x0E = 01110 "8" = 30 = 0x1E = 11110
"r" = 15 = 0x0F = 01111 "9" = 31 = 0x1F = 11111
The digits "0" and "1" and the letters "o" and "l" are not used, to
avoid transcription errors.
--
boy...@pobox.com http://pobox.com/~boykin ICQ: 5118680
Key fingerprint = 159A FA02 DF12 E72F B68F 5B2D C368 3BCA 36D7 CF28
Richard Buckle
Me again. I was wondering if anyone has written Crypto++
encoder/decoder classes for Base32, as described in "Building Secure
Software" by Viega and McGraw:-
<http://www.buildingsecuresoftware.com/>
<http://www.buildingsecuresoftware.com/bss_examples-1.0.tar.gz>, file "EX15-1"
Essentially this is a case-insensitive base 32 encoding using [A-Z]
and [0-9] but excluding 0, 1, o and l, for a total of 32 symbols:-
static char b32table[32] = "ABCDEFGHIJKMNPQRSTUVWXYZ23456789";
Any punctuation character such as such as "-" or "." can be used as a
separator. The scheme fits nicely into a power of 2 and avoids the
common confusions about case and between the four excluded characters.
Ideally, a Base32Encoder class should have optional constructor
parameters exactly like HexEncoder's, to choose between upper and
lower case and set a grouping interval and separator character. I'd
suggest that it should default to lower case, as lower case
characters are more quickly distinguished by the human eye.
If no-one has done one, any pointers on how best to write it? I've
had a good look at HexEncoder and Base64Encoder and their
superclasses and helpers, but I'm new to this framework and I suspect
there are requirements on the class interface that I don't know
about. Basically, I don't feel qualified to attempt a Base32Encoder
and Base32Decoder before talking to you all.
TIA,
Richard.