Paul Rubin wrote: > Michael Sparks <[EMAIL PROTECTED]> writes: >> I'm looking at using this library and to familiarise myself writing >> small tests with each of the ciphers. When I hit Crypto.Cipher.ARC4 >> I've found that I can't get it to decode what it encodes. This might >> be a case of PEBKAC, but I'm trying the following: > > You have to reinitialize the cipher state for decryption, as someone > else explained. You also have to make sure that keys are unique and > independent for separate messages.
Hmm... Thanks for this. > For most applications you probably > want to think about adding authentication. Indeed - though I'm working bottom up. How a key gets transfered from a to b safely will be another step. Another one will be how to trust that exchange, for how long, and how much, etc. I'm well aware that this is a well trod area though, hence why I'm working bottom up. > In general you shouldn't > use arc4 unless you know what you're doing. Having looked at how it works from a user perspective, it's fairly inappropriate anyway, due to wanting to work over unreliable channels anyway. > What's the application? Components for secure communications and identity confirmation. Use cases: * Signing content multicast by the BBC to indicate that it came from the BBC. (ohh, so many issues :-) * Signing content captured on a mobile device such that we know that it came from that mobile. Specific high level use case of that is to be able to accept contributions from people from arbitrary devices and know who they came from. Perhaps embedded in the essence. * Related to that would be the ability to tag content with rights [1] information, and to know it's not been tampered with. [1] eg Who created it. When? Has it been published/broadcast or not? When? Have additional rights over and above fair use/dealing been granted (eg creative commons attribution license). * Similarly people want the ability to protect data in transit between trusted end points. Some people using the system would probably be looking to build restrictions management as well, but that's largely beyond the scope of our system. Indeed restrictions management would require breaking our system. For these use cases to work, encryption & digest tools are clearly an option, and hence having components that support encryption and digest are (to say the least) useful. They're obviously not the only techniques though. 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 :-) Given the pycrypt library docs page starts off with: "This documentation assumes you have some basic knowledge about the Python language, but not necessarily about cryptography." I do for example know enough about cryptography to know that me devising my own approach is foolhardy. Thus the statement above appealed :) As a result I decided to sit down and learn how to use this to form some basic components for encryption/decryption. Given another part early in the docs was """A central goal of the author's has been to provide a simple, consistent interface for similar classes of algorithms.""" I decided to start off with "sketches" implementing minimal examples for each digest and cipher. I'm now working through the Public Key examples. 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. I supsect we'll end up looking at or wrapping some other library instead/as well, but it struck me as a nice starting point. 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. Thanks for the comments, Michael. -- [EMAIL PROTECTED], http://kamaelia.sourceforge.net/ British Broadcasting Corporation, Research and Development Kingswood Warren, Surrey KT20 6NP This message (and any attachments) may contain personal views which are not the views of the BBC unless specifically stated. -- http://mail.python.org/mailman/listinfo/python-list