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

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

[Mark Gaiser]

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]

Best regards,
Mark Gaiser

[1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/crypto.c
[2] there are plugins to make it possible but then you have the extra
requirement of a plugin
[]3 No, not HLS/MPD! They serve a different purpose. Extending them to
serve my purpose is a lost goal to begin with so let's not even go there.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Wed, Dec 21, 2022 at 4:44 PM Mark Gaiser <markg85@gmail.com> 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
>

To amend, a more accurate example of how it currently works is this:
ffplay crypto://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
>

To amend this too.
The result should be no need to provide "crypto://". The ffmpeg file format
detection should detect that ".crypto" should be handled by the crypto
plugin.


>
> 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]
>
> Best regards,
> Mark Gaiser
>
> [1] https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/crypto.c
> [2] there are plugins to make it possible but then you have the extra
> requirement of a plugin
> []3 No, not HLS/MPD! They serve a different purpose. Extending them to
> serve my purpose is a lost goal to begin with so let's not even go there.
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]

Mark Gaiser (12022-12-21):
> 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 concat demuxer can already contain options, and despite is name it
can be used with a single file.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Thu, Dec 22, 2022 at 11:40 AM Nicolas George <george@nsup.org> wrote:

> Mark Gaiser (12022-12-21):
> > 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 concat demuxer can already contain options, and despite is name it
> can be used with a single file.
>

Could you elaborate on how to use that:?

The end result needs to be:
ffplay <file>

that needs to translate to:
ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv
$AES_IV

I briefly looked at the concat demuxer but couldn't see how to get this
desired result.
If you know how, please let me know!



>
> Regards,
>
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Hendrik Leppkes]

On Thu, Dec 22, 2022 at 4:53 PM Mark Gaiser <markg85@gmail.com> wrote:
>
> On Thu, Dec 22, 2022 at 11:40 AM Nicolas George <george@nsup.org> wrote:
>
> > Mark Gaiser (12022-12-21):
> > > 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 concat demuxer can already contain options, and despite is name it
> > can be used with a single file.
> >
>
> Could you elaborate on how to use that:?
>
> The end result needs to be:
> ffplay <file>
>
> that needs to translate to:
> ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv
> $AES_IV
>
> I briefly looked at the concat demuxer but couldn't see how to get this
> desired result.
> If you know how, please let me know!
>

Create a file like this:
https://pastebin.com/hFSeXsZt

The first line is so ffmpeg can probe the format, then just have a
"file" line followed by any number of "option" lines.

Note that options are only allowed if safe-mode is disengaged, so the
app in question would have to pass "-safe 0" to the execution in some
manner. But this is something you would have to ask the app to do, as
this protection exists for a reason.

- Hendrik
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Gregor Riepl]

> The result should be no need to provide "crypto://". The ffmpeg file format
> detection should detect that ".crypto" should be handled by the crypto
> plugin.

Instead of a custom descriptor file format that is only used for this 
particular special case, you could also define a custom URI, such as:

encrypted-media://key-format:aes128/key:12345667abcdef/iv:12345678/uri:file%3A%2F%2F%2Ftmp%2Ffile.mp4

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Thu, Dec 22, 2022 at 8:15 PM Gregor Riepl <onitake@gmail.com> wrote:

> > The result should be no need to provide "crypto://". The ffmpeg file
> format
> > detection should detect that ".crypto" should be handled by the crypto
> > plugin.
>
> Instead of a custom descriptor file format that is only used for this
> particular special case, you could also define a custom URI, such as:
>
>
> encrypted-media://key-format:aes128/key:12345667abcdef/iv:12345678/uri:file%3A%2F%2F%2Ftmp%2Ffile.mp4
>
>
I can't find a single thing about this in the ffmpeg documentation.
How is this called, where can I read more about it and - most importantly -
does it work out of the box?

An option that I'm looking for should work without providing custom
arguments in ffmpeg!

Regardless, this would be a rather big security hole as a potential key
would be plainly visible in url logging.
Therefore "hiding" it in a file is probably a better and more secure
approach.


> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Tomas Härdin]

ons 2022-12-21 klockan 16:44 +0100 skrev Mark Gaiser:
> 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.

This sounds like business logic. Fix KODI instead. Much of this can
also be handled by any competent OS at the filesystem layer.

/Tomas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Fri, Dec 23, 2022 at 12:05 PM Tomas Härdin <git@haerdin.se> wrote:

> ons 2022-12-21 klockan 16:44 +0100 skrev Mark Gaiser:
> > 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.
>
> This sounds like business logic. Fix KODI instead. Much of this can
> also be handled by any competent OS at the filesystem layer.
>

Then M3U as a format is business logic too.
HLS and MPD are business logic too.
At least, based on your comment, they would fall into that same category.

The difference between those formats and my suggestion?
M3U -> playback of very specific formats
"crypto" -> playback of anything ffmpeg supports

M3U has a file format.
crypto has none.

Say a hypothetical streaming service (no, i don't have ambitions to start
one) would want to give access to higher quality and different codecs then
is possible with HLS/MPD.
A service like that currently has to invent their own custom format,
probably as a fork of ffmpeg, to accomplish this. With a file format for
crypto this functionality would just exist.

I'm suggesting that giving crypto this file format would be a win with not
even that much effort on the ffmpeg code side.


> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 451 bytes --]

Mark Gaiser (12022-12-23):
> Then M3U as a format is business logic too.
> HLS and MPD are business logic too.
> At least, based on your comment, they would fall into that same category.
> 
> The difference between those formats and my suggestion?

First difference: they point to several files, yours is about a single
file.

Second difference: they exist out there, yours you are trying to invent
just for that.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Fri, Dec 23, 2022 at 5:34 PM Nicolas George <george@nsup.org> wrote:

> Mark Gaiser (12022-12-23):
> > Then M3U as a format is business logic too.
> > HLS and MPD are business logic too.
> > At least, based on your comment, they would fall into that same category.
> >
> > The difference between those formats and my suggestion?
>
> First difference: they point to several files, yours is about a single
> file.
>

They actually point to N files. Could also be just 1.
Also, they could use this proposed ".crypto" file as their files.


> Second difference: they exist out there, yours you are trying to invent
> just for that.
>

That's just lame.
I'm not trying to invent it just to invent something. I have an actual need
for this where this would be a solution.


>
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 193 bytes --]

Mark Gaiser (12022-12-23):
> They actually point to N files. Could also be just 1.

Wow, what an interesing and crucial distinction for the discussion.

Goodbye.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Gregor Riepl]

> I can't find a single thing about this in the ffmpeg documentation.
> How is this called, where can I read more about it and - most importantly -
> does it work out of the box?

No, it does not.
This was a suggestion that sounds like a better option than a custom 
metadata descriptor file that is only used for one particular use case, 
at least to me.

> Regardless, this would be a rather big security hole as a potential key
> would be plainly visible in url logging.
> Therefore "hiding" it in a file is probably a better and more secure
> approach.

The same applies to your custom descriptor file, of course. Especially 
if it's stored on disk, as ramdisks/pipes/sockets aren't as ubiquitous 
as you might think.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Tomas Härdin]

fre 2022-12-23 klockan 17:31 +0100 skrev Mark Gaiser:
> On Fri, Dec 23, 2022 at 12:05 PM Tomas Härdin <git@haerdin.se> wrote:
> 
> > ons 2022-12-21 klockan 16:44 +0100 skrev Mark Gaiser:
> > > 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.
> > 
> > This sounds like business logic. Fix KODI instead. Much of this can
> > also be handled by any competent OS at the filesystem layer.
> > 
> 
> Then M3U as a format is business logic too.
> HLS and MPD are business logic too.
> At least, based on your comment, they would fall into that same
> category.
> 
> The difference between those formats and my suggestion?
> M3U -> playback of very specific formats
> "crypto" -> playback of anything ffmpeg supports
> 
> M3U has a file format.
> crypto has none.
> 
> Say a hypothetical streaming service

Having to invent hypotheticals does not really help your case. The ipfs
gateway debacle is still fresh.

That we want to avoid having keys in the command line is not
unreasonable. A -keyfile argument for crypto: might be appropriate.

/Tomas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 401 bytes --]

Tomas Härdin (12022-12-26):
> That we want to avoid having keys in the command line is not
> unreasonable. A -keyfile argument for crypto: might be appropriate.

You are confusing two threads, the issue of credentials visible in the
command line is for another proposal. This here is about giving options
without giving options, which is a recurring topic.

Regards,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Tomas Härdin]

mån 2022-12-26 klockan 12:00 +0100 skrev Nicolas George:
> Tomas Härdin (12022-12-26):
> > That we want to avoid having keys in the command line is not
> > unreasonable. A -keyfile argument for crypto: might be appropriate.
> 
> You are confusing two threads, the issue of credentials visible in
> the
> command line is for another proposal. This here is about giving
> options
> without giving options, which is a recurring topic.

Right. And trying to smuggle in command line options via a file feels
made for exploitation..

/Tomas

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 432 bytes --]

Tomas Härdin (12022-12-26):
> Right. And trying to smuggle in command line options via a file feels
> made for exploitation..

This is why my proposal years ago was rejected by Reimar.

And this is why concat requires -safe to accept options.

To be fair, limiting the case to cryptographic keys would probably not
be exploitable, but it is a half measure, too specific to a particular
use case.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Mon, Dec 26, 2022 at 12:18 PM Tomas Härdin <git@haerdin.se> wrote:

> mån 2022-12-26 klockan 12:00 +0100 skrev Nicolas George:
> > Tomas Härdin (12022-12-26):
> > > That we want to avoid having keys in the command line is not
> > > unreasonable. A -keyfile argument for crypto: might be appropriate.
> >
> > You are confusing two threads, the issue of credentials visible in
> > the
> > command line is for another proposal. This here is about giving
> > options
> > without giving options, which is a recurring topic.
>
> Right. And trying to smuggle in command line options via a file feels
> made for exploitation..
>

Why so skeptical in that negative demotivating tone?

Isn't any media file "sneaking in options"?
M3U is one, though more of a meta file, it itself doesn't actually store
video data.
MKV is one. It can have wildly different content which defines how the file
is decided/presented.
.. and so you have literally every file ffmpeg supports.

What I'm proposing is conceptually no different than m3u.
I'm even adding in a version to, from a parsing point of view, have some
points to require to be in that file and only handle those that are
"spec-definned".
The file isn't magically going to add in more options that ffmpeg would
blindly swallow, that was never the intention!

My intent with this thread was to start a constructive chat about how to
create a "container format" for encrypted data that we could all agree on.
It would allow encrypted file handling for tools that embed ffmpeg.
A feature that sooner or later will be needed if decentralized storage is
going to be a big thing.

I for example would have liked to know if adding in a key in that file
would be acceptable.
Or if that must be like M3U meaning the key comes from a server and is
never stored in that file.

I suppose the question really is:
1. Should I discuss it further here? With the idea to get to a defined file
format to implement that we agree on!
2. Should I just go for it, make it without further feedback, perhaps show
how it works in a video some months from now. Then try to get this accepted
as PR that implements it (no further feedback requested)? That would be too
late imho hence wanting to discuss it _before_ developing it.

I'm all ears!


>
> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 3623 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer <michael@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@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Ronald S. Bultje]

Hi Mark,

On Tue, Dec 27, 2022 at 5:47 PM Mark Gaiser <markg85@gmail.com> wrote:

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

There's multiple things going on here, and you're sort of putting them all
together to solve all problems at once:
- a mechanism for crypto-data exchange in your application or server/client
protocol
- a way for your application to pass the crypto-data to the underlying
library

I think once you split these out as separate entities, you'll see that you
don't necessarily need the same solution for it. The second one, in
particular, is already solved in FFmpeg, and this is called an AVOption.
(And the first question is really out of FFmpeg scope anyway.) Have you
considered simply using AVOption, and/or is there a reason AVOption isn't a
suitable solution for your use case?

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Wed, Dec 28, 2022 at 3:27 PM Ronald S. Bultje <rsbultje@gmail.com> wrote:

> Hi Mark,
>
> On Tue, Dec 27, 2022 at 5:47 PM Mark Gaiser <markg85@gmail.com> wrote:
>
> > 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.
> > [..]
> >
> 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.
> >
>
> There's multiple things going on here, and you're sort of putting them all
> together to solve all problems at once:
> - a mechanism for crypto-data exchange in your application or server/client
> protocol
> - a way for your application to pass the crypto-data to the underlying
> library
>
> I think once you split these out as separate entities, you'll see that you
> don't necessarily need the same solution for it. The second one, in
> particular, is already solved in FFmpeg, and this is called an AVOption.
> (And the first question is really out of FFmpeg scope anyway.) Have you
> considered simply using AVOption, and/or is there a reason AVOption isn't a
> suitable solution for your use case?
>
> Hi Roland,

There's definitely multiple things going on but it's not what you summarize.

1. DEV (me) goes to the mailing list to propose a new feature. Dev tries to
be concise and to the point to not litter the request with irrelevant side
details.
2. MU (mailing list user) is skeptical and needs more context - which is
great!
3. DEV gives more context
4. MU now discusses irrelevant side-details that DEV tried to prevent in
the initial post - this is where things go wrong
5. Topic is now derailed with side suggestions that have nothing todo with
the initial proposal. Feature potentially never gets built.

Point 5 is where we're roughly at right now. I will make this feature
because I need to have it for my own project.

I'm fine discussing the proposed format further.
I know _exactly_ what i want to do.

Today this works:
ffplay crypto://encrypted_file -decryption_key $AES_KEY -decryption_iv
$AES_IV

I'm proposing:
ffplay encrypted_file.crypto

The ".crypto" file hides the details that you'd otherwise have to pass
manually.

I am proposing a format for that file and was hoping for constructive
feedback to make sure I develop a format that is OK by the ffmpeg team and
could potentially be accepted when I send it as a PR.
That is the discussion I wanted to have here.
Not needless back and forth in details that "matter to my endgoal" but
don't matter for the feature i'm proposing.

With regards to your AVOption option remark.
What you don't say, but imply by it, is implementing ".crypto" support on a
per-application basis completely outside of ffmpeg.
That's a total 180 turn of what I meant to ask and not the intention at all!
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 333 bytes --]

Mark Gaiser (12022-12-28):
> There's definitely multiple things going on but it's not what you summarize.

You forgot the bit where “MU” told you your proposal was mostly
redundant, too limited and ad-hoc and would have security implications
if more generic, and “DEV” conveniently ignored it.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Wed, Dec 28, 2022 at 5:22 PM Nicolas George <george@nsup.org> wrote:

> Mark Gaiser (12022-12-28):
> > There's definitely multiple things going on but it's not what you
> summarize.
>
> You forgot the bit where “MU” told you your proposal was mostly
> redundant, too limited and ad-hoc and would have security implications
> if more generic, and “DEV” conveniently ignored it.
>
> Ok, that made me laugh :)

Please correct me as I'm probably wrong.
But where did anyone say that there was a working alternative solution that
did not require customizing how ffmpeg is used?
Like disabling safe.

I intend for this to be there by default.


> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 459 bytes --]

Mark Gaiser (12022-12-28):
> > Ok, that made me laugh :)

I did not write that. And that feels rude.

> Please correct me as I'm probably wrong.
> But where did anyone say that there was a working alternative solution that
> did not require customizing how ffmpeg is used?
> Like disabling safe.

Heuristics to not require safe in cases where it is quite safe would be
much more acceptable than a redundant ad-hoc format.

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Wed, Dec 28, 2022 at 5:30 PM Nicolas George <george@nsup.org> wrote:

> Mark Gaiser (12022-12-28):
> > > Ok, that made me laugh :)
>
> I did not write that. And that feels rude.
>
> > Please correct me as I'm probably wrong.
> > But where did anyone say that there was a working alternative solution
> that
> > did not require customizing how ffmpeg is used?
> > Like disabling safe.
>
> Heuristics to not require safe in cases where it is quite safe would be
> much more acceptable than a redundant ad-hoc format.
>

That works for me.
But is that feasible?

My thinking is that you'd need to parse the entire file (the concat thing)
to know if it is safe or not.


>
> --
>   Nicolas George
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 9448 bytes --]

Hi

On Tue, Dec 27, 2022 at 11:46:38PM +0100, Mark Gaiser wrote:
> On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer <michael@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..

I would encrypt it with gpg with Bs public key then send it to B by a
secure way, the way depends on what i know of from B
* physically give him a usb stick or send that by snail mail
* upload it somewhere through tor browser, B then could download it too
  using tor browser.
  
If the material is of value to some state actor (hello CIA/NSA/FSB/Mosad)
then additional precautions are probably a good idea. (seperate computers, use of
internet connections not associated with either A or B and so forth) ive not yet
had the need to do this so i have not really thought about it

I somewhat avoid all these "paid by giving your data away to advertisers"
companies even for things 100% intended to be public. At least when its
easy to avoid them.
But i dont want to slide too far off topic here, just replying ...


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

iam not against the idea in principle. 
Some maybe technical detail here is that the unencrypted  .crypto file
should never be stored on disk. Because its leaking the AES key and anyone
with physical access to the machine later could potentially obtain that key.
A better solution may be to only store the .crypto file encrypted with gpg
so when libavformat accesses it, gpg (agent) would look in it and check if 
it has a matching private key. if so it would decrypt it in accordance to
its configuration. 
From the user side the user could get a popup asking if the file should be
decrypted and if needed for the users password protecting the private key.
This is the same you would get today when you use gpg and have it configured
accordingly.
The main goal here is to never have the decrypted .crypto file on disk, just
to pass the encrypted one through gpg and use that to then decrypt teh main
multimedia material.

of course something else than gpg can be used but iam thinking that it
wouldnt hurt if more people had gpg setup properly and knew how to use
it in this world of mass surveliance. So having gpg as an option could be
interresting.

About URLs in the .crypto file
full URLs always pose some risk for privacy. There is some risk for
tracking here if its a remote destination.
This is something that should probably be thought through carefully.

example: if one use case is to have the crypto file in the same place
as the multimedia. Example:

someplace/zksnark-lecture5.mp3.encrypted
someplace/zksnark-lecture5.mp3.crypto.gpg

then maybe that could be handled different from a case like
zksnark-lecture5.mp3.crypto.gpg
    Which then points to https://clicktracker-redirector.evil/someplace/zksnark-lecture5.mp3.encrypted

Because teh first can be done more privately then if a different remote
location is needed and allowed
    
thx

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Ronald S. Bultje]

Hi,

On Wed, Dec 28, 2022 at 11:14 AM Mark Gaiser <markg85@gmail.com> wrote:

> On Wed, Dec 28, 2022 at 3:27 PM Ronald S. Bultje <rsbultje@gmail.com>
> wrote:
>
> > Hi Mark,
> >
> > On Tue, Dec 27, 2022 at 5:47 PM Mark Gaiser <markg85@gmail.com> wrote:
> >
> > > 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.
> > > [..]
> > >
> > 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.
> > >
> >
> > There's multiple things going on here, and you're sort of putting them
> all
> > together to solve all problems at once:
> > - a mechanism for crypto-data exchange in your application or
> server/client
> > protocol
> > - a way for your application to pass the crypto-data to the underlying
> > library
> >
> > I think once you split these out as separate entities, you'll see that
> you
> > don't necessarily need the same solution for it. The second one, in
> > particular, is already solved in FFmpeg, and this is called an AVOption.
> > (And the first question is really out of FFmpeg scope anyway.) Have you
> > considered simply using AVOption, and/or is there a reason AVOption
> isn't a
> > suitable solution for your use case?
> >
> > Hi Roland,
>
> There's definitely multiple things going on but it's not what you
> summarize.
>
> 1. DEV (me) goes to the mailing list to propose a new feature. Dev tries to
> be concise and to the point to not litter the request with irrelevant side
> details.
> 2. MU (mailing list user) is skeptical and needs more context - which is
> great!
> 3. DEV gives more context
> 4. MU now discusses irrelevant side-details that DEV tried to prevent in
> the initial post - this is where things go wrong
> 5. Topic is now derailed with side suggestions that have nothing todo with
> the initial proposal. Feature potentially never gets built.
>
> Point 5 is where we're roughly at right now. I will make this feature
> because I need to have it for my own project.
>
> I'm fine discussing the proposed format further.
> I know _exactly_ what i want to do.
>

But why? This is not a format. It's not a container, or a playlist. It's an
artificial key/value exchange protocol created just for you. That's even
the specific purpose of this format: it has no other purpose than to
circumvent AVOption because it's ... complicated? I really don't understand
why this is preferable over AVOption. Yet, you refuse to discuss this.

And aside: the "DEV" and "MU" people in your story are much more than a
fabulous white hat hacker vs. internet troll which you make it out to be
(in what order?). Don't forget "MU" carries the long-term maintenance
burden. This is not derailing; this is called design review.

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Mark Gaiser]

On Wed, Dec 28, 2022 at 10:02 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> Hi
>
> On Tue, Dec 27, 2022 at 11:46:38PM +0100, Mark Gaiser wrote:
> > On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer <
> michael@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..
>
> I would encrypt it with gpg with Bs public key then send it to B by a
> secure way, the way depends on what i know of from B
> * physically give him a usb stick or send that by snail mail
> * upload it somewhere through tor browser, B then could download it too
>   using tor browser.
>
> If the material is of value to some state actor (hello CIA/NSA/FSB/Mosad)
> then additional precautions are probably a good idea. (seperate computers,
> use of
> internet connections not associated with either A or B and so forth) ive
> not yet
> had the need to do this so i have not really thought about it
>
> I somewhat avoid all these "paid by giving your data away to advertisers"
> companies even for things 100% intended to be public. At least when its
> easy to avoid them.
> But i dont want to slide too far off topic here, just replying ...
>
>
> >
> > 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.
>
> iam not against the idea in principle.
> Some maybe technical detail here is that the unencrypted  .crypto file
> should never be stored on disk. Because its leaking the AES key and anyone
> with physical access to the machine later could potentially obtain that
> key.
> A better solution may be to only store the .crypto file encrypted with gpg
> so when libavformat accesses it, gpg (agent) would look in it and check if
> it has a matching private key. if so it would decrypt it in accordance to
> its configuration.
> From the user side the user could get a popup asking if the file should be
> decrypted and if needed for the users password protecting the private key.
> This is the same you would get today when you use gpg and have it
> configured
> accordingly.
> The main goal here is to never have the decrypted .crypto file on disk,
> just
> to pass the encrypted one through gpg and use that to then decrypt teh main
> multimedia material.
>
> of course something else than gpg can be used but iam thinking that it
> wouldnt hurt if more people had gpg setup properly and knew how to use
> it in this world of mass surveliance. So having gpg as an option could be
> interresting.
>

I see!
What you're describing here is a much more interesting approach for sure!

To be frank, I don't think I can implement that. I have some crypto
knowledge and get the concept but implementing that in code is a lot more
difficult.
I can probably implement my suggested file format :)

Say, for the sake of the workflow in user applications, that one would
implement your suggestion.
The .crypto file would only ever exist in encrypted form on disc.
Now how would the flow go from opening that file to a user interaction?
The way I see it is that "some callback" needs to happen from ffmpeg to the
user.
But as far as I'm aware, no such interaction scheme exists in the ffmpeg
context?

Could you paint me a workflow example of how this can be implemented?
Ideally with no changes on applications using ffmpeg.


>
> About URLs in the .crypto file
> full URLs always pose some risk for privacy. There is some risk for
> tracking here if its a remote destination.
> This is something that should probably be thought through carefully.
>
> example: if one use case is to have the crypto file in the same place
> as the multimedia. Example:
>
> someplace/zksnark-lecture5.mp3.encrypted
> someplace/zksnark-lecture5.mp3.crypto.gpg
>
> then maybe that could be handled different from a case like
> zksnark-lecture5.mp3.crypto.gpg
>     Which then points to
> https://clicktracker-redirector.evil/someplace/zksnark-lecture5.mp3.encrypted
>
> Because teh first can be done more privately then if a different remote
> location is needed and allowed
>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker.
> User
> questions about the command line tools should be sent to the ffmpeg-user
> ML.
> And questions about how to use libav* should be sent to the libav-user ML.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 12244 bytes --]

On Thu, Dec 29, 2022 at 03:51:24PM +0100, Mark Gaiser wrote:
> On Wed, Dec 28, 2022 at 10:02 PM Michael Niedermayer <michael@niedermayer.cc>
> wrote:
> 
> > Hi
> >
> > On Tue, Dec 27, 2022 at 11:46:38PM +0100, Mark Gaiser wrote:
> > > On Tue, Dec 27, 2022 at 10:40 PM Michael Niedermayer <
> > michael@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..
> >
> > I would encrypt it with gpg with Bs public key then send it to B by a
> > secure way, the way depends on what i know of from B
> > * physically give him a usb stick or send that by snail mail
> > * upload it somewhere through tor browser, B then could download it too
> >   using tor browser.
> >
> > If the material is of value to some state actor (hello CIA/NSA/FSB/Mosad)
> > then additional precautions are probably a good idea. (seperate computers,
> > use of
> > internet connections not associated with either A or B and so forth) ive
> > not yet
> > had the need to do this so i have not really thought about it
> >
> > I somewhat avoid all these "paid by giving your data away to advertisers"
> > companies even for things 100% intended to be public. At least when its
> > easy to avoid them.
> > But i dont want to slide too far off topic here, just replying ...
> >
> >
> > >
> > > 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.
> >
> > iam not against the idea in principle.
> > Some maybe technical detail here is that the unencrypted  .crypto file
> > should never be stored on disk. Because its leaking the AES key and anyone
> > with physical access to the machine later could potentially obtain that
> > key.
> > A better solution may be to only store the .crypto file encrypted with gpg
> > so when libavformat accesses it, gpg (agent) would look in it and check if
> > it has a matching private key. if so it would decrypt it in accordance to
> > its configuration.
> > From the user side the user could get a popup asking if the file should be
> > decrypted and if needed for the users password protecting the private key.
> > This is the same you would get today when you use gpg and have it
> > configured
> > accordingly.
> > The main goal here is to never have the decrypted .crypto file on disk,
> > just
> > to pass the encrypted one through gpg and use that to then decrypt teh main
> > multimedia material.
> >
> > of course something else than gpg can be used but iam thinking that it
> > wouldnt hurt if more people had gpg setup properly and knew how to use
> > it in this world of mass surveliance. So having gpg as an option could be
> > interresting.
> >
> 
> I see!
> What you're describing here is a much more interesting approach for sure!
> 
> To be frank, I don't think I can implement that. I have some crypto
> knowledge and get the concept but implementing that in code is a lot more
> difficult.
> I can probably implement my suggested file format :)
> 

> Say, for the sake of the workflow in user applications, that one would
> implement your suggestion.
> The .crypto file would only ever exist in encrypted form on disc.
> Now how would the flow go from opening that file to a user interaction?
> The way I see it is that "some callback" needs to happen from ffmpeg to the
> user.
> But as far as I'm aware, no such interaction scheme exists in the ffmpeg
> context?
> 
> Could you paint me a workflow example of how this can be implemented?
> Ideally with no changes on applications using ffmpeg.

Ive not implemented this so i may be slightly wrong but the way i
understand it is
you call gpg to ask it to decrypt the data piped into it or by some other
means like gpgme. Gpg then looks if a gpg-agent is running (this may be even on a
different machiene if you run "ffmpeg -> gpg" through a ssh session)
that gpg-agent then looks into itself to see if it has a 
private key / password that it can use, if it needs a password it will
run the configured pinentry program to ask the user for the password of her
private key. That can be cached depending on configuration. There are
also different pinentry programs, to match different GUI and text mode
environments.). These pinentry programs could in principle itself have
some sort of database and rules to cache passphrases.
once gpg-agent has everything it will securely decrypt the
data for you while none of the keys ever get stored on disk, and the
private keys stay on the user system even if the decryption happens
on a remote sytem. Thats at least how i understand it.

libavformat should not really need to do anything beyond asking gpgme
to decrypt it i think if gpg and gpg-agent are setup correctly
If that ffmpeg program is run by the user she may get a popup for her
private key password.
If she wants to run this in a script without her interaction she only
has to make sure the gpg-agent has key/passphrase cached. (which is
a bit iffy security wise, so would be better to use a seperate private
key for automated decryption)

Note: while i used gpg many times as a user, i have never used gpgme
as a developer, so i am not the right one to really ask about it :)

PS: before you spend alot of time on implementing this, try to make sure
people who had objections in this thread are ok with this too.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".