On Wed, Dec 28, 2022 at 10:02 PM Michael Niedermayer <mich...@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 < > mich...@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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
