[Ffmpeg-devel] [RFC] MXF AES decryption
Sat Jan 13 18:51:01 CET 2007
On Sat, Jan 13, 2007 at 06:24:30PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 13, 2007 at 02:13:37PM +0100, Reimar D?ffinger wrote:
> > updated version.
> > Note that it still contains two unrelated hunks:
> > the one I sent in "[PATCH] respect type when resolving MXF strong ref"
> > and one simplifying klv_decode_ber_length, hope that makes reviewing not
> > too inconvenient, if it does just review those before and I'll send a
> > new patch after they are applied ;-)
> > The key in AVFormatParameters is supposed to be a string for easier
> > extensibility and easy way to specify on commandline mostly.
> iam unhappy with this, what about per stream keys? and why not simply
> pass a uint8_t array? also i hate AVFormatParameters why not use
> AVFormatContext ?
Well, but then you need some way to assign a certain key to a certain
stream (unless we just try them all *g*). That's why I thought about a
string that could later be parsed in a more complex way. But I have no
problem changing this. Other suggestions are welcome, too, though I
wouldn't like to implement this in some complicated way right now.
> > The current format is just a hex string like "02045a...", 32 characters for
> > AES-128 (the only format supported currently).
> > IMO openssl should be replaced, it is too bloated for such a simple
> > functionality but I'm not yet sure by what, not to mention that I am not
> > up to date if it still has such an inconvenient license...
> <random bloated crpto lib> dependance for just AES is completely unacceptable
> write your own 2 page implementation of AES
That two pages is for the AES algorithm, you either need 5+ pages of
tables or initialization. Tables would be really large and
initialization code a lot of effort.
Also libgcrypt is not quite that bloated, 300 k binary. Ok, it is
Hm. it's unclear to me if this would be LGPL-compatible though.
More information about the ffmpeg-devel