Paul Rubin wrote: > Michael Sparks <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list