[Patches] [ python-Patches-868496 ] base64.py support for RFC 3548

[SourceForge.net]

Patches item #868496, was opened at 2003-12-31 11:34
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470

Category: Library (Lib)
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Barry A. Warsaw (bwarsaw)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: base64.py support for RFC 3548

Initial Comment:
I needed more complete RFC 3548 support, so I hacked up
the base64.py module.  Here's the patch and an updated
test suite.


----------------------------------------------------------------------

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-01-03 19:59

Message:
Logged In: YES 
user_id=12800

Thanks Tim, I'll change the default for map01 and fix
b16decode.  I'll leave additional claims of cryptographic
security to the upcoming report by the PSF's CSO <wink>.

I'm also removing the freenet_* methods.  Updating docs,
test cases, and checking in.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-01-03 18:30

Message:
Logged In: YES 
user_id=31435

Don't worry about speed -- if necessary, we can speed it 
after it's been checked in.

I found the b32decode map01=False argument confusing.  
Maybe because the default was named False, I assumed the 
only other sensible value for it would be True.  Maybe just 
changing the default to None would be clearer.

b16decode internals should not allow the input string to 
contain '=' characters, since base 16 encoding doesn't use a 
pad character.

I assume you'll add suitable doc changes.

Just for fun, I'd like to see the docs claim that base64 and 
base32 encoding are cryptographically secure, unless the 
map01 argument is set to 'L' <wink>.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-01-03 14:55

Message:
Logged In: YES 
user_id=12800

Freenet alphabet is mentioned in the thread referenced by
footnote [8] in the RFC. 

Thanks for the other suggestions.  I'll work with those and
unless there are any other objections, I'll commit these
changes soon.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-01-03 06:21

Message:
Logged In: YES 
user_id=21627

Where does the Freenet encoding come from? Do we need that?

Performance of the algorithms can probably be improved. For
example, for base32
- _b32table should be a list (or tuple), not a dictionary:
  _b32table = tuple([_b32table[i] for i in range(32)])

- first hexlifying the string on encoding seems wasteful;
use struct instead

def f2(chunk):
    c1, c2, c3 = struct.unpack("!HHB", chunk)
    c2 += (c1 & 1) << 16 # total 17 bits
    c3 += (c2 & 3) << 8  # total 10 bits
    parts = [_b32table[c1 >> 11],
             _b32table[(c1 >> 6) & 31],
             _b32table[(c1>>1) & 31],
             _b32table[c2 >> 12],
             _b32table[(c2 >> 7) & 31],
             _b32table[(c2 >> 2) & 31],
             _b32table[c3 >> 5],
             _b32table[c3 & 31]]
    return ''.join(parts)

Apart from that, the change looks good.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=868496&group_id=5470