From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id AAAC242274 for ; Tue, 27 Dec 2022 21:40:45 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B8EDE68B612; Tue, 27 Dec 2022 23:40:41 +0200 (EET) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 9C3B3680034 for ; Tue, 27 Dec 2022 23:40:35 +0200 (EET) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id D711A1BF206 for ; Tue, 27 Dec 2022 21:40:34 +0000 (UTC) Date: Tue, 27 Dec 2022 22:40:33 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20221227214033.GS3806951@pb2> References: MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] Would a crypto file be acceptable? X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============3573196719474898448==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============3573196719474898448== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="w89FjbBIqlQz+8Ov" Content-Disposition: inline --w89FjbBIqlQz+8Ov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2022 at 04:44:59PM +0100, Mark Gaiser wrote: > Hi, >=20 > The ffmpeg crypto protocol handler [1] allows one to play encrypted media. >=20 > 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! >=20 > 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. >=20 > Playback of encrypted data works like this: > ffplay encrypted_file -decryption_key $AES_KEY -decryption_iv $AES_IV >=20 > 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 we= ll > 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] >=20 > My idea is to make a new file format that would be implemented and specced > within [1]. My proposed format would be: >=20 > --- > CRYPTO-VERSION:1 > CRYPTO-KEY:URI:..... > CRYPTO-IV:URI:..... > encrypted_file > --- >=20 > 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 HE= X. >=20 > The above proposed format should be stored in a file with ".crypto" as > extension. The crypto plugin [1] would then handle that file. The argumen= ts > 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:. Or with one of the other types. >=20 > 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. >=20 > Playing encrypted media would be as simple as: > ffplay file.crypto >=20 > 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 i= s ? 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 [...] --=20 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 .= =2E." --w89FjbBIqlQz+8Ov Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCY6tmSgAKCRBhHseHBAsP qw5sAJ9p7LHx1n+YzRvdLXfQ4ELWHdC8gwCfbsWjZnyoT4dSOKLY5OEbr79t1HQ= =YVKm -----END PGP SIGNATURE----- --w89FjbBIqlQz+8Ov-- --===============3573196719474898448== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============3573196719474898448==--