Re: 添付ファイルテスト

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 07:30 [raw]

そんな制限があるなか添付ファイルを送りつ余裕はあまりありませんね。Base64エンコードするとだいたい元のファイルサイズの倍増えるみたいですし。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 07:39 [raw]

BinSend は、大きいファイルを分割してくれる、と書いてある。 https://github.com/AyrA/BinSend 試してないけど。 C# で書かれてるみたいね。 どうでもいいけど、 BinSend って名前が便箋みたいでいい感じ。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 08:13 [raw]

BinSendはWindowsアプリケーションですね。もう半年以上前になりますが、試してもうまく動きませんでした。 私の環境はLinuxなので(Windowsアプリケーションも動かせないことはないですが面倒)Windows環境の人がいたら試してみてほしいですね。 便箋って語感がよくて覚えやすいですね。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 10:47 [raw]

Torでアップローダーに上げて、ここでURLを晒すが正解

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 10:54 [raw]

とても使いやすいアップローダーにhttps://transfer.shというのがあってこれは便利です。簡単にCLIからアップロードできるうえに、onionサイトとしても運営しているのでTorでファイルアップロードするにも便利だったんですよ。 最近まではお金の問題でシャットダウンするそうだったんですが、また今は持ち直しているようです。 ここにアップロードされたものは2週間で消されるし、登録などもいらないから続いてほしいです。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:08 [raw]

アップローダからダウンロードしたファイルが、 本当に URL を晒した者がアップロードしたものかどうかを 確かめるには、どうしたらいいの? アップロードする前に署名して、ダウンロードした側も署名を確認するのかな。 署名の公開鍵は URL を晒したのと同じチャンネルで公開するのかな。 それだと、署名の手間がかかる。 Bitmessage に添付できれば、署名が自動になって楽だ。 そもそも Bitmessage が Email に優越している点のひとつはそこだ。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:19 [raw]

そうですね。デタッチ署名くらいなら流せそうです。どんなにファイルサイズが大きくても署名そのものは大きくなりませんから。ただ、chanのアドレスでURLを流した人がいてその人がデタッチ署名をつけていても、それは同じchanに参加している誰かが流したことになって結局のところ署名で真正性を確かめることはできないのではないでしょうか。 偽のファイルをアップロードしてそのファイルに署名をつけてデタッチ署名を流すという一連の行為は全ての人が行えますし、BMのメッセージは時系列に受信できる保証はありません。ですから、 「そのURLは偽物だ!」 「いいや、そのURLこそ偽物だ!」 となり、結局誰がアップロードしたのかわからなくなります。 なのでアップロードした人はURLを流すときに自分のアドレスでデタッチ署名も同時に流しておく必要があると考えます。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:27 [raw]

でも結局のところそのファイルをアップロードした人が本当に期待した人かどうかはわかりません。なにせ誰もどのアドレスについて保証しないのですから。この点は匿名性と身元の保証のトレードオフなのではないでしょうか。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:34 [raw]

さっき「同じチャンネル」と言ったのは、 chan のことではなくて、「同じ経路」という意味でした。 自分のアドレスを使う必要があるのは、同意です。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:49 [raw]

同じ経路というのがよくわかりませんが、どこかにアップローダを定めてそこを使い続けるということでしょうか? だとしても、誰かが同じように実行できる方法ではだめです。私達はchanにいる以上、そのchanのアドレスとそこに向けられる個々のアドレス以外に情報を得ることはできません。その個人のアドレスと期待している人物とが簡単に紐付けられている場合はそもそも匿名ではありませんし、匿名である以上誰もそのアドレスと結びついている人は誰なのかを知り得ないので保証できません。 ただしそのアドレスの人が発信した情報であるかは自明です。発信する人が自分のアドレスで投稿すればいいだけだからです。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:51 [raw]

先に言ったのは、どういう経緯かはともかく、ある Bitmessage アドレスを信頼したとして、 アップローダにアップロードされたファイル、あるいはメッセージに添付されたファイルが 信頼できるかどうかの問題。 そもそもある Bitmessage アドレスを信頼できるかどうかは、別問題です。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:56 [raw]

それならばその信頼している人が自分のアドレスで公開鍵をBitmessage上に流して、それを受けた人は示されたURLからダウンロードしたファイルの署名をその公開鍵で検証すればいいだけなのではないでしょうか?

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 11:58 [raw]

おっしゃるとおり、同じ経路、というのは、 URL と署名を同じ Bitmessage アドレスから送信して相手に伝える、ということを言っていました。 アップローダは関係ありません。 言葉が足りず申し訳ないです。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 12:11 [raw]

ファイルの認証については、そのとおりです。 ただ、署名の処理を別に行なうのが面倒だということです。 Bitmessage なら自動で署名がされるので、 それに添付できればファイルも自動で署名されて便利だと。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 12:22 [raw]

なるほど。しかしそれでも難しい問題がありますね。その投稿内容をそのままそっくり誰かが個人アドレスを使って投稿した場合、確かにURLも署名も検証に成功しますから、個人アドレスAと個人アドレスBの人のどちらが本当はファイルをアップロードしたのか区別がつかないです。つまりなりすましが簡単に成功してしまいます。chanアドレスの場合はそもそも信用できないとみなして破棄すればいいです。 A「URLはxxxx、公開鍵はxxxx、署名はxxxxです。」 これをBも全く同じに投稿した場合、どちらが実は本当のアップロードした本人なのかがわからないということです。 せめて時系列の保証がされていれば一番最初に投稿した人が本人であると信用の材料になるのですが、それもありません。 公開鍵xxxxは確かにアドレスAのものである、とわかるか、何かしらAだけが残せる痕跡をファイルにつけられれば良いです。しかしその前提を満たすことができるでしょうか。 私が今とっさに思いついたアイデアでは、 証明したいAがchanで「アドレスaに対してハッシュ値H(sk_a)、アドレスbに対してハッシュ値H(sk_b)、アドレスcに対してハッシュ値H(sk_c)を送信した。シークレットの復元はH(sk)である。」と広告します。sk_aはaにだけ直接渡したシークレットな値で、sk_bならbに対してです。 そのsk_a,sk_b,sk_cは他ならぬ証明者Aしか知りません。 そしてアドレスa,b,cの人たちは互いにシークレット値を交換し合います。このシークレット値は秘密分散というもので、一定数のシークレットが揃わないとそのシークレットからは何も復元できないというものです。そのため、シークレットをお互いに集めあって復元できたものとそれぞれのシークレットをchanで公開します。 このとき、aは確かに証明者Aの広告したとおりのシークレットとそれによる復元を明かします。 bもcも同様に明かします。 これ以外の人たちはa,b,cが明かしたシークレットの値が証明者Aが広告したものと同じであるかをハッシュ値によって検証します。そしてシークレットの復元を信用します。 たとえばそのシークレットの復元は証明者Aの公開鍵であったとすれば、a,b,cたちによって取り出した値であり、彼らによって不完全ではありますが証明者Aの公開鍵が明らかにされたわけです。 しかし結局のところa,b,cは全く別の人である必要があり、そうなるとは保証できませんし、結託されてしまえば同じことです。 難しいですね。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 12:28 [raw]

それならば、そのファイルを添付した人のアドレスが信用できるものなら署名も要りませんね。 そのアドレスを使用したメッセージを送信できるのはそのアドレスの所有者以外にいないので、その人がファイルを添付してきたとなればそれだけで信用できます。 実用上の障壁は「そのアドレスを信用するための根拠がない」「ファイルサイズの著しい制限がある」 というところでしょうか。 アドレスAの人が管理できているスペースがどこかのWebにあって、そのWebとアドレスAの人とが結びつけばいいんですよね。 それならばアドレスAの人が「私のスペースはここだよ」と言ってしまって、それを信用すればいいのですが、 アドレスBの人が同じことを言ってしまうとなりすましになってしまうので、どこかで信用できるアドレスを見出さなければなりません。 かゆいところに手が届かないですね。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 12:55 [raw]

難しいことはよく分からないので、基本だけで考えます…。 A がアップロードして、 X がダウンロードしたとする。 アップロードしたのが他ならぬ A であることは確認できる。 X が十分な長さのランダムな文字列を生成し、 その文字列を A から署名してもらって、署名が正しいのを確認できれば、 A は確かに署名の秘密鍵を持っていると確信できる。 A を真似る者が沢山いて誰が本当の A か分からなくても、 すべての人に同じチャレンジをして判断できる。 みなが chan に居るなら、 chan で 1 回チャレンジをすれば十分。 もちろん、不正解も沢山届くかもしれないけれども、それはスパムみたいなもので…。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 13:07 [raw]

>A がアップロードして、 X がダウンロードしたとする。 >アップロードしたのが他ならぬ A であることは確認できる。 それならばそもそも署名の検証などはいらないかと。Aの示したファイルをXが受け取ったということが確かならそれ以上に何かを確かめる必要はないはずです。 >X が十分な長さのランダムな文字列を生成し、 >その文字列を A から署名してもらって、署名が正しいのを確認できれば、 >A は確かに署名の秘密鍵を持っていると確信できる。 署名が正しいかどうかは公開鍵がなければ検証できません。署名を作るだけなら誰でもどのファイルに対してでも可能ですから。 公開鍵があってこそ初めて誰の作った署名なのかが判明します。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 13:16 [raw]

Bitmessage アドレスは(署名と暗号化の 2 つの)公開鍵から生成されるものです。 メッセージ(あるいは添付ファイル)に署名がなければ、本当にそのアドレスから(署名の秘密鍵の所有者から) 送信されたものなのか分かりません。 第三者から内容を改竄される可能性もあります。 なので Bitmessage は内部で署名の処理をしています。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 1 13:22 [raw]

>A がアップロードして、 X がダウンロードしたとする。 >アップロードしたのが他ならぬ A であることは確認できる。 「すなわち、その確認方法として以下」ということでした。 >X が十分な長さのランダムな文字列を生成し、 >その文字列を A から署名してもらって、署名が正しいのを確認できれば、 >A は確かに署名の秘密鍵を持っていると確信できる。 またしても言い方が悪くてごめんなさい。 > 公開鍵があってこそ初めて誰の作った署名なのかが判明します。 前提として、 A や A を真似た人たちは、 同一の公開鍵を chan などで公開しているのではないのですか?

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 2 08:06 [raw]

CLI(これは、言い換えれば、多くのダウンロードとXのダウンロードで可能です)。 誰もが難しいことを理解できないので、私は同じデータのことができますので、私はお互いに思いついた言葉がありません:それは同じルートを大きく成長する? もしそれがアドレスのために有用であれば、そのBitMessageは同じです。 それは自動的になりますし、人に添付ファイルをテストするためにはちゃんが添付ファイルをテストしなければならないことは間違いないと指摘されています。メールに決めることができますのでお互いに追加することを決定する必要があります メッセージは、正確にエンコードされたメッセージで、時系列順に表示されます。制限も到着しますが、署名は共謀です:匿名ではないので、私は真実を知ることができません。 Bitmessageの人物で成功したと考えられるアドレスからのファイル以外の情報は、最初に続行するよう指示されます。

BM-2cTxxzfXv45ZRxLFrV5BNRSt3z9drKveT2
Dec 4 14:52 [raw]

あんまりでかい画像はBitMessageでは送るのは無理かなあ。通信技術は向上していて5Gとかが出るみたいだけど、 それよりもっといい圧縮技術があればなあ。 そう思っていた矢先いいニュースが。 http://blogs.articulate.com/rapid-elearning/heres-a-free-app-to-compress-your-images/ 簡単に要約すると、ズームアウトしてもパッと見気づかないようなまでに画質の劣化を抑えてなおかつ かなりの圧縮率を誇る画像圧縮する技術がリリースしまして、https://squoosh.app/で利用できるようです。無料です。 これを使えば旅の写真などの画質を保持したままBitMessageで流すなんてことができるかもしれませんね。

BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc
Dec 5 08:45 [raw]

犬の目玉が気持ち悪い (´・ω・`)

[chan] Bit_Message_JA
BM-2cT7XHTa1L1iCiGVdg8AezKnnJf36yHmGc

Subject Last Count
迷惑メール報復策 Dec 17 09:57 2
(no subject) Dec 17 09:40 5
プロクシ無しで周知 Dec 17 09:38 2
Tor Browser から bitmessage.org Dec 15 01:50 1
( ゚д゚)... Dec 14 09:42 8
壁紙添付テスト Dec 7 23:43 13
添付ファイルテスト Dec 7 13:20 5
転送テスト Dec 7 02:12 1
Re: 添付ファイルテスト Dec 5 08:45 23
beamstat Dec 5 08:16 6
無題 Dec 5 07:20 1
久しぶりに戻ってきた Dec 2 23:21 16
Re: sshからcliでそ��そうしんてすと Dec 1 07:33 1
sshからcliでそ��そうしんてすと Dec 1 05:48 1
(no subject) Dec 1 05:35 1
CLIてすと Dec 1 05:35 3