[FFmpeg-devel] Would a crypto file be acceptable?

[Mark Gaiser]

On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer <michael at niedermayer.cc>
wrote:

> On Wed, Dec 21, 2022 at 04:44:59PM +0100, Mark Gaiser wrote:
> > Hi,
> >
> > The ffmpeg crypto protocol handler [1] allows one to play encrypted
> media.
> >
> > The great thing here is that it allows playback of any media format that
> > ffmpeg supports!
> > Have a container format like mkv as an encrypted blob, no problem for the
> > crypto plugin!
> >
> > I'm explicitly mentioning mkv (though there's many more) here because
> that
> > isn't possible in HLS/MPD. While those streaming formats handle
> encryption
> > too, they are very limited in terms of supported codecs and containers.
> >
> > Playback of encrypted data works like this:
> > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV
> >
> > While this works just fine, it's limited in use because the cryptography
> > details have to be passed on the command line. Applications that might
> well
> > support much of ffmpeg functionality can't easily hook into the crypto
> > functionality. Take KODI for example, it allows playback of many of the
> > formats ffmpeg supports but anything with crypto just isn't possible. In
> > fact, anything that requires custom command line arguments isn't
> possible.
> > [2]
> >
> > My idea is to make a new file format that would be implemented and
> specced
> > within [1]. My proposed format would be:
> >
> > ---
> > CRYPTO-VERSION:1
> > CRYPTO-KEY:URI:.....
> > CRYPTO-IV:URI:.....
> > encrypted_file
> > ---
> >
> > The URI would be a format type identifier where you can choose between
> URI
> > (to pass a URL to a key blob), BASE64URL (key encoded as base64url) or
> HEX.
> >
> > The above proposed format should be stored in a file with ".crypto" as
> > extension. The crypto plugin [1] would then handle that file. The
> arguments
> > would be filled based on the "properties" in the file. So for example the
> > `decryption_key` argument would be populated with the blob returned from
> > CRYPTO-KEY:URI:<url>. Or with one of the other types.
> >
> > The "encrypted_file" would just be passed through ffmpeg's
> > "ffurl_open_whitelist" like the crypto plugin currently does. Meaning
> that
> > the file could be anything ffmpeg supports.
> >
> > Playing encrypted media would be as simple as:
> > ffplay file.crypto
> >
> > With this mail I'm looking for a confirmation if the above concept would
> be
> > allowed as a patch for ffmpeg? And if not, how can I achieve the same
> > results in a way that would be acceptable? [3]
>
> I understand what you are trying to do but not what the use case for this
> is ?
>
> Encryption has the goal to let one party access data and not another.
> Who are these 2 parties and where does the encrypted media come from?
>
> You mention decentralization, I see nothing related to decentralization
> in this. Or do you suggest that, everytime someone succeeds decrypting a
> file its key would be automatically be published in a decentralized
> public database, so teh next user can safe herself teh troubble from
> finding the key?
>
> If not iam confused why you store keys plainly in files, because this is
> not very secure, so maybe the goal never is to keep the key safe ?
> Or it doesnt matter that someone with physical access in the future would
> also possibly have access to the key. Again you didnt explain the use case
> and who the intended user and adversery is ...
>

How do you privately want to share a video with someone else? Say A (you)
and B (the other)
Currently you probably use one of the following options or something
similar:
- A uploads it you youtube as unlisted and share that link with B
- A adds it to google photos/drive and share that link B
- A adds it to cloud storage and shares that link with B
etc..

The common denominator in all those examples is where and how it's stored.
The data is stored in supposedly private storage.
You trust that storage to be private and trust the link to be between you
and the intended target.tended party.

In this setup your video, that is not intended to be public, is shared.
This works and is the "web2" way of doing things.

Now enter web3.
Storage now is publicly available to everyone in the distributed world of
web3.
I know, or can know, what you host and vice versa.
If I were to follow the above sharing model the video - which you had
intended to be private - is now very publicly available.

That's what I'm trying to fix (and am nearly there)!
How I'm fixing this is as follows (this is a bit outside the scope of the
initial question but its context might help you frame the question
properly):
- A has a public and private key pair. So does B.
- A knows the public key of B and vice versa.
- Both A and B have data which is encrypted on their end with keys
unrelated to their own public and private keys
- (this is the important bit!) Wrapped around their private data is a
"metadata" file where their own private key serves to encrypt/decrypt that
file
- A can now re-encrypt the metadata to the public key of B and share that
metadata with B.
- B can now play the file backed by the metadata that A intended to share.
- The result being file sharing where you can access it if:
 -- you have access to the distributed storage
 -- you have the keys to decrypt the metadata
---- This all works already, right here and now on my pc! ----

The tricky part here is for anyone using this scheme to play this file.
Right now i'm doing this with a command line like:
ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv
$AES_IV

For brevity's sake, consider the "metadata" file named above to be the
_encrypted_ version of the ".crypto" file i'm proposing.
For B to play it, B must decrypt that file (now it's like the proposed
.crypto file) and can now happily play this file in ffmpeg-backed players
that allow the proposed crypto file.

This is just one version of how things can work.
In this version the decrypted metadata file does contain the key and iv.

An alternative version for example uses the "lit protocol"
https://litprotocol.com/ to get the key to decrypt the data.
Another alternative version could get the key from a "server" just like HLS
does it.
There's many ways to do this key part. My intention for now was to keep it
"simple" and have the key in the file itself.
I'm including a version "field" for the very purpose of later extending it
with additional features.

But this, along with the crypto file idea as a whole, is why I made this
thread. Feedback and ideas are very welcome!

I hope this elaborate explanation did a good job in making clear why I want
this and what it's intended use is.
You'd be right to say if there is no use for it yet. Nothing exists yet
that works this way. If distributed and open access storage networks are
going to grow as hard as they have been in recent years then adding in
encryption is sooner or later going to be a requirement for some uses.
There are already niche projects offering encrypted storage including
sharing. However, these mechanisms are often based on user B accessing a
site where they can access the shared encrypted data. You again have that
reliance on a site that must be there to see your data even though you
might well be able to access all of it. You just can't decrypt it without
the site being around. This crypto file idea is also solving that as all
you need is the data itself and the keys, no reliance on external services
at all.


>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 1
> "Used only once"    - "Some unspecified defect prevented a second use"
> "In good condition" - "Can be repaird by experienced expert"
> "As is" - "You wouldnt want it even if you were payed for it, if you knew
> ..."
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>