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

[Michael Sparks]

Paul Rubin wrote:

> Michael Sparks <michaels at rd.bbc.co.uk> 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.
-- 
Michael.Sparks at rd.bbc.co.uk, 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.