RetroSearch Browse

Sat Jan 13 19:21:11 CET 2007 · https://ffmpeg.org/pipermail/ffmpeg-devel/2007-January/027346.html

Hi

On Sat, Jan 13, 2007 at 06:51:01PM +0100, Reimar D?ffinger wrote:
> Hello,
> 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.

what about adding the key to AVStream?

> 
> > > 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.

nonsense the whole algo needs about 1k of tables, its 85 lines of code
in the reference implementation for the tables (
wc boxes-ref.dat
  85 1099 5612 boxes-ref.dat
)

now 512 bytes of these tables are just inverses of the other 512 bytes
a= TAB0[b] -> b= TAB1[a] style this is trivial

one of the 256 byte tables is just
last= 1;
for(i=0; i<256; i++){
    Alogtable[i]= last;
    last ^= last<<1;
    if(last>255) last ^= PRIMITIVE_POLY; 
}

the other i think should be something like

inv= Alogtable[255-Logtable[i]]
inv ^=   (inv<<1) ^ (inv<<2) ^ (inv<<3) ^ (inv<<4)
       ^ (inv>>7) ^ (inv>>6) ^ (inv>>5) ^ (inv>>4) ^ 99;
S[i] = inv&255;

and someone should shoot the people who wrote the wikipedia page for
AES, they have successfully converted a trivial algorithm in a obfuscated
mess

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070113/62355a68/attachment.pgp>

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://ffmpeg.org/pipermail/ffmpeg-devel/2007-January/027346.html below:

[Ffmpeg-devel] [RFC] MXF AES decryption