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

[Michael Niedermayer]

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

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 ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20221227/948d9c7c/attachment.sig>