Blowfish in Python?

Markus Stenberg mstenber at cc.Helsinki.FI
Wed Mar 1 09:14:18 EST 2000


"Richard Brodie" <R.Brodie at rl.ac.uk> writes:
> "Michael Zawrotny" <zawrotny at gecko.sb.fsu.edu> wrote in message
> news:slrn8bnveq.1jn.zawrotny at gecko.sb.fsu.edu...
> > Markus,
> > On 29 Feb 2000, Markus Stenberg <mstenber at cc.Helsinki.FI> wrote:
> > > Hmm.. As far as I'm concerned, shifts for example do screw up.
> 
> > > 0xffffffff >> 30
> > >
> > > [64bit Python: 3]
> > > [32bit Python: -1]
> > >
> > > As far as I'm concerned, that should _not_ happen. Or maybe it's just me.
> >
> > In an ideal world, perhaps not.  It does seem to be one of those places
> > that the standard allows implementors some leeway in behavior.  K&R 2nd
> > Ed. p. 49 says:
> Yes but I hope we're not into saying - if 'C' does it it must be right ;)

Indeed.

> Java, for example, has two right shift operators, so the behaviour is
> well defined. The Python documentation is fairly clear that sign
> extension is required; so the C implementation, at least, looks broken
> in that it relies on undefined behaviour.

Yes.. And I consider Python implementation to be broken as well, i.e. I
think notation should be something perverted like -0x80000000 to 0x7fffffff
or something if we really pretend to hide all OS details.

> When I try with ints and long ints, I get:
> 
> 0xffffffff >> 30 = -1
> 0xffffffffL >> 30 = 3L
> 
> Which is perhaps unexpected but having -1 >> 30 different from
> -1L >> 30 is worse, IMHO. I think the heart of the problem is that
> 0xffffffff != 0xffffffffL. Presumably the literal 0xffffffff isn't -1 on a
> 64bit Python either.

Indeed, see above. Having basically 31bit integer type makes implementing
almost any encryption algorithms even moderately efficiently a nightmare.
[i.e. so far, my Blowfish-in-Python project, with both
32bit-ints-with-hacked-operators and genuine-Python-longs have both been
_ways_ too slow, and thus unusable]

I wish Python had some sort of consistent bit-oriented integer type and
"logical value" integer type :P (for instance, >> and & behavior on typical
Python integer represents "logical" and "machine-oriented" behavior,
respectively)

Current mess just makes portability pain, and forces one to use 31bit
integer and/or longs, both of which are highly inefficient for
compute-bound tasks. 

Toying-with-idea-of-writing-C-extension-as-we-speak-ly, Markus

-- 
	Only in the silence voice, Only in the darkness light, 
	Only in dying life; The hawk's bright flight on the empty sky
		-- Ursula Le Guin / (the) Earthsea Quartet



More information about the Python-list mailing list