Crypto.Cipher.ARC4, bust or me doing something wrong?

Michael Sparks ms at cerenity.org
Wed Sep 21 21:54:36 CEST 2005


Paul Rubin wrote:
> Michael Sparks <michaels at rd.bbc.co.uk> writes:
>> Rather than re-inventing wheels I thought I'd pick a library sit down
>> and see how pycrypt's meant to be used before actually going anyway.
>> (Amongst other reasons, this is why I suspected me, rather than the
>> library :-)
> 
> Pycrypt doesn't operate at anything like the level you need.  It just
> gives you low level cipher primitives.  You need higher level protocols.

Agreed. As I say I'm building up systems slowly on this front, and part of
the aim will be to show how outright dumb it is to build these things
without a decent understanding of the underlying tech.

Sadly there's many people (where I work) who don't understand how easy
it is to get these things wrong, and unfortunately practical demonstration
is one of the few languages people listen to :-/

This is where I border on being unprofessional so I'll be quiet at that
stage :-((

On a more positive note, as I say I picked something simple initially, and
have no intention at this stage of it being the primary approach.

>> FWIW, I'm well aware how easy it is to get cipher/digest/etc based
>> security/id systems wrong. I'm really starting with pycrypt because it
>> looked simple enough, low level enough and self contained enough to
>> act as a base for working with existing more complex systems.
> 
> Do yourself a favor and stick to something standard like TLS, rather
> than cook up your own protocol.  There are some Python wrappers for
> OpenSSL or GNU TLS, for example.

If those operated over multicast then they'd be an option... However...

Incidentally our primary use is to indicate *integrity* of data not to
prevent content being viewed. It's also obviously susceptible to attack
in many ways. Again, I'd say more offline about this - Usenet is just the
wrong place for it.

>> Anyway, once I've gone through all of the existing digests/ciphers/PK
>> ciphers, I'll post the snippets up on our site as raw examples for
>> pycrypto, which will hopefully be a) correct usage b) be useful to
>> others.
> 

> You really need to know a lot more than it sounds like you know, 

*shrug* It's not a matter of what I don't know it's a matter of showing how
things can be used, and I want to use it (internally) to demonstrate what
goes wrong when people try to design their own systems naively.

One way to learn is to build. 

> to have any chance of getting fancy protocol designs correct.

FWIW, I have little intention of inventing something new (in terms of
protocols) /if/ possible. What these components will be used for is to
demonstrate how they work inside, and what goes wrong if people try to
reinvent wheels.

Quite frankly we *should* be using a crypto professional, however that's
currently not a realistic option :-((( As a result currently it's up to me
to demonstrate here the risks involved in creating your own system.

>  http://www.cs.ucdavis.edu/~rogaway/classes/227/spring05/book/main.pdf
> 
> is a textbook that will show you how to do this, or at least give you
> an idea of what you're dealing with.  Watch out, it is rather theoretical.

That's fine/great :) - thanks for the reference :-)

FWIW, I *do* have a good idea of what I'm dealing with, //which is why// I'm
pessimistic about getting it right. I might have more experience with these
things than those I'm working with, however I am very aware of my
(current :) limits. Hopefully I'll be able to use these tools educate those
around me why rolling your own is an idea fraught with issues.

Best Regards,


Michael.
        



More information about the Python-list mailing list