| Re: Android版:DXアーカイブの暗号化機能について ( No.7 ) |
- 名前：was-blue.0793 日時：2018/11/04 02:18
>>管理人様
ご返答ありがとうございます。
暗号化されたDXアーカイブを使う一般的な目的は著作権保護だと思いますので、"暗号化されたDXアーカイブを著作権保護の目的にのみ使う限り"問題はなくなってくると思います。
(無料で入手可能なフリー素材を入れていると少し微妙になってきそうではありますが……)
「DXアーカイブの機能を著作権保護の目的以外に使う場合アプリの配信に規制がかかる」旨の文章はどこかに書いておいた方がいいかもしれません。
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.8 ) |
- 名前：yumetodo 日時：2018/11/04 14:46
でたよ、PGPのソースコードを書籍出版する必要に迫られた闇の規制。
ところでこれはDxArchiveの暗号機能を利用していなくてもDxLibとリンクすると対象となるように思われます。
つまり自力で当該部分を除去してビルドしない限りにおいて、すべてのケースで少なくとも届出が必要と読めてしまいませんかね・・・？
PC向けについても、米国内、ないしワッセナー・アレンジメントでの合意等に基づき同様の法拘束をかけている国
(日本では外為法第25条？範囲がいまいちわからない)
に拠点を置く企業のサービスを利用して配布した場合同様に対象になるように見えます。
したがってDxArchiveの暗号機能はDxLibに含めず、別のライブラリとするべきではないでしょうか？
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.9 ) |
- 名前：was-blue.0793 日時：2018/11/05 14:23
>>yumetodo様
以前mp3の特許が生きていた頃に私がmp3を非対応化する質問をした時も似たような問題があったと記憶していますが、
Windows向けかつ国内のみを対象とした場合でも暗号化には似たような規制があるのでしょうか？
アメリカから輸出する場合の暗号の規制はDXアーカイブを使う目的が「著作権保護に限定されていれば」規制の対象から外れると理解しましたが、
このような法的な問題(日本にも同様の規制がある？こと)を考えると、yumetodo様の提案通りDXアーカイブの機能はDXライブラリから独立させた方がいいように思います。
SHA-256を使うだけなら一方向性で復号不可能なので、(ファイルの同一性を検査することを目的とするなどで)SHA-256ハッシュを取得することは問題ないようにも思いますが……
(Wikipediaにもアルゴリズムが公開されていますし)
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.10 ) |
- 名前：管理人 日時：2018/11/06 01:26
> was-blue.0793さん
> 「DXアーカイブの機能を著作権保護の目的以外に使う場合アプリの配信に規制がかかる」旨の文章はどこかに書いておいた方がいいかもしれません。
ご提案ありがとうございます
検討してみます
> このような法的な問題(日本にも同様の規制がある？こと)を考えると、yumetodo様の提案通りDXアーカイブの機能はDXライブラリから独立させた方がいいように思います。
別ライブラリにしてしまうと使い勝手の良さが大幅に低下するので独立させるのは避けたいところです
> yumetodoさん
> ところでこれはDxArchiveの暗号機能を利用していなくてもDxLibとリンクすると対象となるように思われます。
> つまり自力で当該部分を除去してビルドしない限りにおいて、すべてのケースで少なくとも届出が必要と読めてしまいませんかね・・・？
規制の対象にならない場合は届出の必要はないという認識なのですが、そうではなくて規制の対象外でも届出は必要なのでしょうか？
> 8127さん
すみません、No.1 のお書き込みで『DXアーカイブのver1.05以前は共通鍵方式で12bit』と仰られていますが、
こちらはどのような計算で 12bit と導き出されるのでしょうか？
ver1.05では鍵文字列の最大長は12文字なので、12 * 8 = 96bit ではないのでしょうか？
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.11 ) |
- 名前：yumetodo 日時：2018/11/06 05:23
ええっと自分でも何を言っているかわからなくなりつつありますが、改めて整理を試みます。
ttp://dsas.blog.klab.org/archives/52146838.html
をみつつ話を進めます。
まずDxLibとリンクしたすべてのアプリケーションおよびDxLib自身(暗号機能部分を自力で除去した場合を除く)が対象と言ったのは
>02 “Software” as follows
> (see List of Items Controlled)
>(中略)
> c.1. “Software” having the characteristics, or
> performing or simulating the functions of the
> equipment, controlled by 5A002;
が根拠と思われたからです。
DxLib自体には明らかに暗号機能が含まれているので該当し、
利用するアプリケーションもリンクする(GPLとおなじく静的/動的の差異はないと思われる)以上、
その実行可能binaryを含む可能性があります(Link Time Optimizationで運良く吹き飛んだら別ですが)
ただし、
1. ESRのCategory 5, Part 2 で規制されるか
2. 1のときにECCNによる番号分類による手続きの差
を考える必要があり、1で規制されない場合は届け出すら不要です。
先に届け出と言ったのは2で「一般に公開されている暗号ソースコード」に該当するので許可例外TSUが適用でき、
それが届け出するだけだという話でした。
で、具体的に見ていくわけですがちょっと眠いので寝ます。
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.12 ) |
- 名前：8127 日時：2018/11/06 07:34
管理人さま、
＞ver1.05では鍵文字列の最大長は12文字なので、12 * 8 = 96bit ではないのでしょうか？
12bitではなく12byteの間違いです(もうしわけない)
個人的には、
A.別ライブラリに分離
B.マクロで変更できるようにする(暗号化を排除したいユーザーはdxlibを自前ビルドしないといけない)
C.むしろkeyを56bitに落としてしまう
D.暗号化のあるなしのビルド済ライブラリを両方配布する
くらいですかね・・・(管理人さまの手間が増えてしまいますが私はD推しです)
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.13 ) |
- 名前：yumetodo 日時：2018/11/06 23:06
というかlibを分ければいいのではないかなと。そしてVSユーザー向けには#pragmaによるlib自動読み込みはやらないようにして必要な人は各自libを依存追加する。
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.14 ) |
- 名前：管理人 日時：2018/11/07 00:27
> yumetodoさん
> 1. ESRのCategory 5, Part 2 で規制されるか
> を考える必要があり、1で規制されない場合は届け出すら不要です。
私はこちらの『届け出すら不要』という認識なのですが、yumetodoさんの認識は違うのでしょうか？
> 8127さん
> 12bitではなく12byteの間違いです(もうしわけない)
なるほど、了解です
> A.別ライブラリに分離
> B.マクロで変更できるようにする(暗号化を排除したいユーザーはdxlibを自前ビルドしないといけない)
> C.むしろkeyを56bitに落としてしまう
> D.暗号化のあるなしのビルド済ライブラリを両方配布する
ＤＸライブラリをビルドしなければならなかったり、別ライブラリにするとプログラム中級者以上の方しか
使えなくなり、且つ使おうとする方も減ってしまうので選択肢としては C か D に絞られますが、
現状配布するライブラリの容量がかなり大きくなってしまっていますので D も選択肢から外れ、
選ぶとしたら残る C になります
56bit でも自動解析で暗号化解除されないような仕組みを考える必要がありますね…
というか、個人的には
E.現状のままで問題ない
だと思っているのですが、8127さんの認識もこちらではないのでしょうか？
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.15 ) |
- 名前：was-blue.0793 日時：2018/11/07 01:03
>>管理人様
暗号化の目的が「知的所有権・著作権保護」に限定されていれば確かに届け出の必要はないのですが、この辺りはライブラリ利用者がDXアーカイブをどう扱うかによって変わってきます。
(暗号機能を含むことが日本でいう"技術的保護手段"に該当するかということです)
しかしライブラリ自体は現状維持で問題ないとしてもアプリを配信する時、「このアプリは暗号機能を含んでいますが、その目的は知的所有権・著作権保護目的に限定されています」というような一文を
アプリ内、もしくはGoogle Playの説明などに含む必要が出てくるように思います。
さらにそのことの証明を求められた時、どうするかはまた考える必要がありますが……
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.16 ) |
- 名前：yumetodo 日時：2018/11/07 13:04
ゆっくり読み直した結果
1. DxLib自体→届け出(許可例外TSU)が必要(例えばGithub Releaseとかchocolateyとかその他パッケージマネージャ経由でbinaryを配布するとき。
日本での配布は調べていないので不明、ワッセナー・アレンジメントがどう効いてくるのか次第)
2. DxLibのDXA暗号化機能を「知的所有権・著作権保護」のために利用するアプリケーション→届け出不要
3. DxLibのDXA暗号化機能をその他の目的で利用する場合→ECCN番号分類に従って手続きが必要
ちなみにパスワードや公開鍵認証などで開発者のみにアクセスが限定されている配布でも(VPSとか)、まねきTV事件を考えるとグレーかなと思われます。
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.17 ) |
- 名前：8127 日時：2018/11/07 15:13
＞というか、個人的には
＞E.現状のままで問題ない
＞だと思っているのですが、8127さんの認識もこちらではないのでしょうか？
はい、基本的にはそう考えています。
Dxlibのユーザーの中でAndroid(iOS)アプリをストアに公開する人＆著作権を厳密に気にする人は多くない(10人に一人もいないのでは)
と考えているので、"E.現状のままで問題ない"のスタンスを維持しつつ、そういう一部の人にはマクロを定義してリビルドをするなどで
対応できるようにするので良いかなと思っています。
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.18 ) |
- 名前：管理人 日時：2018/11/07 23:30
> was-blue.0793さん
> しかしライブラリ自体は現状維持で問題ないとしてもアプリを配信する時、「このアプリは暗号機能を含んでいますが、その目的は知的所有権・著作権保護目的に限定されています」というような一文を
> アプリ内、もしくはGoogle Playの説明などに含む必要が出てくるように思います。
すみません、『「このアプリは暗号機能を含んでいますが、その目的は知的所有権・著作権保護目的に限定されています」
というような一文をアプリ内、もしくはGoogle Playの説明などに含む必要がある』というような解説がどちらかのウェブサイトか
書籍で言及されていたということでしょうか？
もしくは EAR の原文や日本語訳でそのように解釈できる部分がありましたら、教えていただけないでしょうか？ m(_ _;m
> yumetodoさん
ご確認ありがとうございます
> 1. DxLib自体→届け出(許可例外TSU)が必要(例えばGithub Releaseとかchocolateyとかその他パッケージマネージャ経由でbinaryを配布するとき。
> 日本での配布は調べていないので不明、ワッセナー・アレンジメントがどう効いてくるのか次第)
こちらは現在でも NuGet で配布しているので引っ掛かりますね…
> 8127さん
> Dxlibのユーザーの中でAndroid(iOS)アプリをストアに公開する人＆著作権を厳密に気にする人は多くない(10人に一人もいないのでは)
スマホアプリの開発者の方があまり気にされないのは Androidアプリや iOSアプリは 従来型のWindowsアプリほど簡単にはアプリのファイルに
アクセスできないからかもしれません
従来型のWindowsアプリの場合はインストールされているフォルダを開けば誰でもアプリのファイルにアクセスできてしまうので、
簡単に中身を見られないようにしたいと考える方は多いです( そもそもＤＸアーカイブのセキュリティ強度を上げたのもそのようなご要望あってのことですし )
was-blue.0793さん、yumetodoさん、8127さんの『ＤＸアーカイブの機能を分離( 若しくはデフォルトでは無効に )すべき』というご意見と
私の『ＤＸアーカイブの機能を内包したままにしたい』という要望を同時に叶えるにはやはり鍵の長さを56bitにするしかなさそうです
( 同時に 56bit前のバージョンの暗号化されたＤＸアーカイブファイルが使えなくなってしまいますが… )
現在手をつけている作業が終わり次第 56bit化に取り掛かろうと思います
すみません、56bit化するに当たって皆様にお訊ねしたいのですが、SHA-256 で導き出される 256bit のハッシュ値の内、
先頭の 56bit( 7byte ) だけ使うようにすれば『鍵の長さは 56bitである』と考えてしまって良いのでしょうか？ (・・;
 |
| Re: Android版:DXアーカイブの暗号化機能について ( No.19 ) |
- 名前：was-blue.0793 日時：2018/11/08 00:12
>>管理人様
すいません、「著作権保護〜」についての一文は私の解釈なので、この一文だけでは足りないかもしれません。
(本当に目的が「知的所有権・著作権保護」に限定されているなら書く必要はないのかもしれませんし……)
暗号化機能を維持しつつ規制に抵触しないようにするためには、やはり鍵を56bit以下にするしかないと思います……
鍵の長さはSHA-256ハッシュの先頭から7byteだけを使うようにすれば問題なさそうではありますが、もととなるSHA-256自体は256bitあるのでそこから鍵の長さが256bitと扱われるかもしれません。
あるいはそのようなハッシュ関数があるかはさておき、出力が7byte以下となるハッシュ関数を使用するという手もあります。
(余談ですが以前話題になっていたDXアーカイブの暗号化を無理矢理解除するツールですが、DXアーカイブの暗号化は技術的保護手段になるので法的にはアウトな代物です)
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.20 ) |
- 名前：yumetodo 日時：2018/11/08 12:09
いや待ってください。許可例外TSUに基づく届け出をしさえすればDxLibは問題ないはずです。届け出なので投げつけて終わりです。
まあうちはちゃんとやってるんやで！というアピールはしておいて損はないと思いますが。
あとは利用者への注意喚起として、
DxLibのDXA暗号化機能をその他の目的で利用する場合→ECCN番号分類に従って手続きが必要
ということをどこかに書いてあげれば親切だと思います。
なにもbreaking changeをする必要はないです。
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.21 ) |
- 名前：8127 日時：2018/11/08 12:43
管理人様、ちょっと待ってください、勘違いです。
＞8127さんの『ＤＸアーカイブの機能を分離( 若しくはデフォルトでは無効に )すべき』
デフォルトで有効（今のまま）で、無効にする場合だけマクロを変えてビルドする必要があると言っています。
（要するにAndroid(iOS)アプリをストアに公開する人は自分で#define DX_NON_ARCHIVE してビルドしてということ、そうでない大半のユーザーは何もしなくていい）
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.22 ) |
- 名前：管理人 日時：2018/11/09 01:17
> was-blue.0793さん
> すいません、「著作権保護〜」についての一文は私の解釈なので、この一文だけでは足りないかもしれません。
> (本当に目的が「知的所有権・著作権保護」に限定されているなら書く必要はないのかもしれませんし……)
普通に使う分にはＤＸアーカイブの暗号化機能は「知的所有権・著作権保護」として使うことしかできないので、
記述は必要ないのではないかと思います
> 鍵の長さはSHA-256ハッシュの先頭から7byteだけを使うようにすれば問題なさそうではありますが、もととなるSHA-256自体は256bitあるのでそこから鍵の長さが256bitと扱われるかもしれません。
> あるいはそのようなハッシュ関数があるかはさておき、出力が7byte以下となるハッシュ関数を使用するという手もあります。
ご見解＆ご意見いただきありがとうございます
yumetodoさんのご指摘で許可例外TSUに基づく届け出をするだけで問題はなさそう、とのことで56bit化は
なくなりそうですが、仮に 56bit化する場合は別のハッシュ関数を探してみます
> (余談ですが以前話題になっていたDXアーカイブの暗号化を無理矢理解除するツールですが、DXアーカイブの暗号化は技術的保護手段になるので法的にはアウトな代物です)
そうなのですね、ズルをするソフト、というイメージではありましたが、明確に違法なものと分類されるとは思いませんでした
> yumetodoさん
> いや待ってください。許可例外TSUに基づく届け出をしさえすればDxLibは問題ないはずです。届け出なので投げつけて終わりです。
> まあうちはちゃんとやってるんやで！というアピールはしておいて損はないと思いますが。
すみません、許可例外TSUの届け出関係を確認してみました
本当にメールを送るだけなのですね、週末に送ってみます
( ただ、当然といえば当然ですが、配布先 URL などが変わったらその都度届出なければならないのですね… )
> あとは利用者への注意喚起として、
> DxLibのDXA暗号化機能をその他の目的で利用する場合→ECCN番号分類に従って手続きが必要
> ということをどこかに書いてあげれば親切だと思います。
普通に使う分にはＤＸアーカイブ内のファイルを読み込む時にしか暗号関係の処理は行われないので、
そのような記述があるとかえって利用者の方が『何か良くないことがあるのか？』と訝しんでしまわないでしょうか？
寧ろＤＸライブラリの暗号関係の処理を「知的所有権・著作権保護」以外の目的で利用する方法というのが思いつきません…
yumetodoさんは何か「知的所有権・著作権保護」以外の目的で利用する方法を思いつきますか？
> 8127さん
> 管理人様、ちょっと待ってください、勘違いです。
> デフォルトで有効（今のまま）で、無効にする場合だけマクロを変えてビルドする必要があると言っています。
すみません、8127さんのお察しの通りの勘違いをしていました m(_ _;m
ご提案の案とは少し異なりますが、暗号機能だけを無効化するためのマクロを追加しようと思います
( ＤＸアーカイブの機能はＤＸライブラリ内でも使用してしまっていて、現在のバージョンでは
ＤＸアーカイブを無効化できないので… )
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.23 ) |
- 名前：yumetodo 日時：2018/11/09 19:46
> yumetodoさんは何か「知的所有権・著作権保護」以外の目的で利用する方法を思いつきますか？
一般的な用途はもちろん知的所有権・著作権保護になると思いますが、例えばHTTP over DXAとかをやれないことはないかなと。
あと忘れてましたがDxLibのbinaryの再頒布をする場合は再頒布する人が許可例外TSUの届け出を投げないとだめですね。
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.24 ) |
- 名前：管理人 日時：2018/11/11 01:24
> yumetodoさん
> 一般的な用途はもちろん知的所有権・著作権保護になると思いますが、例えばHTTP over DXAとかをやれないことはないかなと。
すみません、HTTP over DXA とは何でしょうか？
DXAファイルを通信で何処かに送るなどでしょうか…？
> あと忘れてましたがDxLibのbinaryの再頒布をする場合は再頒布する人が許可例外TSUの届け出を投げないとだめですね。
なるほど
うーんやはり柵が少ないほうが色々扱いやすくなる( あと、暗号関係の専用ソフトでもないのに暗号規制を
気にしなくてはいけないのは煩わしい )ので、やはり鍵を56bit化する方向で進めようと思います
旧バージョンの DxaDecode.cpp は配布し続けるので許可例外TSUの届け出は投げるとして、最新版を使う分には
暗号規制のことは気にしなくて良いようにしようかと
その変更をしたとしても、影響を受けるのは
A.現在暗号化ＤＸアーカイブを使ったソフトの開発を進めていて、且つＤＸライブラリを最新バージョンに更新した方
B.暗号化ＤＸアーカイブを使用して作成したソフトの更新する際にＤＸライブラリを最新バージョンに変更した方
のみなので、( 旧バージョンのＤＸアーカイブでも暗号化していないファイルについては普通に読み込めるように
しようと思います ) 暗号化ＤＸアーカイブを使用されている方には、お手数をお掛けしてしまいますが一度
最新バージョンで再度暗号化ＤＸアーカイブファイルを作成していただくという形で…
Aの方もそこまで多くないと思いますし( 開発中の間は暗号化はしていないかもしれませんし )、Bの方に至っては
殆ど居られないと思います( バグ修正や追加要素でソフトを更新する場合もＤＸライブラリのバージョンは更新しない方が多い )
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.25 ) |
- 名前：yumetodo 日時：2018/11/11 13:57
>DXAファイルを通信で何処かに送るなどでしょうか…？
普通やらないでしょうが不可能ってわけでもないかなと。
いや、そもそもDxLibのbinaryを再頒布する人がまずいないのでは・・・。NuGetあるわけで。
わざわざ強度を下げるのは理解に苦しみます。
---
いやまてよ、更に混乱してきたんですが
質問 G(1)：
機械可読コード形式のソフトウェアの輸出又は再輸出は、
このソフトウェアのソースコードが一般に入手可能な場合、
EARの対象となりますか？
答：ソフトウェアプログラムのソースコードが一般に入手
可能な場合、ソースコードからコンパイルされた機械可読
コードは、一般に入手可能なソフトウェアであり、従って
EAR の対象とはなりません。
これはどう解釈したらいいんだろう。DxLibのソースコードは公開されているから再頒布は規制対象外ってこと？
|
| Re: Android版:DXアーカイブの暗号化機能について ( No.26 ) |
- 名前：管理人 日時：2018/11/11 21:51
> yumetodoさん
許可例外TSU届け出メール送信しました。
> 普通やらないでしょうが不可能ってわけでもないかなと。
そうなんですよ、普通やらないようなことに対してそのような注釈を入れると、
普通に使っているだけでも何か気をつけなければならないのではないかと
思われてしまうのではないかと…
> いや、そもそもDxLibのbinaryを再頒布する人がまずいないのでは・・・。NuGetあるわけで。
実際にＤＸライブラリを使用したプログラミング解説などのサイトで
ダウンロードできるサンプルプログラムにＤＸライブラリのパッケージが
同梱されている場合もありますので、これらのことを仕様とする際に
その都度許可例外TSUを届け出るのは大げさですし、かといって
『ＤＸライブラリは別途”ＤＸライブラリ置き場”からダウンロードしてください』
とすると利便性が下がりますし、規制外にするメリットはあります
> わざわざ強度を下げるのは理解に苦しみます。
強度は下がるかもしれませんが、思えば件のツールもＤＸアーカイブのヘッダの中で
固定の値になってしまう箇所を狙い打ちにして鍵を取り出していたので、ヘッダの
中からそのような部分を除いてしまえば各ファイルの鍵の長さが7byteになって
しまったとしても、少なくとも『プログラムによる固定処理』で鍵が割り出されて
しまうことはなくなるのではないかと思いまして
( そういう意味では、SHA-256 を使う最新版以前の簡易的な xor処理でも、ヘッダから
固定値部分を除いてしまうだけでも良かったかもしれません )
> 質問 G(1)：
> 機械可読コード形式のソフトウェアの輸出又は再輸出は、
> このソフトウェアのソースコードが一般に入手可能な場合、
> EARの対象となりますか？
>
> 答：ソフトウェアプログラムのソースコードが一般に入手
> 可能な場合、ソースコードからコンパイルされた機械可読
> コードは、一般に入手可能なソフトウェアであり、従って
> EAR の対象とはなりません。
>
> これはどう解釈したらいいんだろう。DxLibのソースコードは公開されているから再頒布は規制対象外ってこと？
こちらの日本語訳をそのまま受け取れば規制対象外となりそうですが…
|