「Mozilla､ファイルアップローダ「Send」をテスト公開」記事へのコメント

暗号化

[Anonymous Coward]

動画見た感じだとブラウザで暗号化するのかな。
リンクもブラウザで生成してサーバ経由しないなら安心。
でも復号キーもリンクに含まれるんだから、結局ダウンロードすればMozilla側に漏洩するってことだよね。

Re:

[Anonymous Coward]

ソース [github.com]を読んでみた。

1. 送信側はブラウザー上で暗号鍵を生成して、その暗号鍵で暗号化したファイルをサーバーに送信する(暗号鍵は送らない)。サーバーはそのファイルをダウンロードするためのURLを返す。
2. 送信側はサーバーから返されたURLに暗号鍵の情報をフラグメントID("#"以降の部分)として追加し、(何らかの安全な経路で)受信側に渡す。
3. 受信側は、渡されたURLでサーバーにアクセスする。フラグメントIDはサーバーに送信されない(URLの仕様)。
4. サーバーは、暗号化されたファイルを返す。
5. 受信側は、フラグメントIDから読み取った暗号鍵を使ってブラウザー上でファイルを復号する。

メモリ不足でも「仮想メモリ」が使われるだけ

[Anonymous Coward]

モダンブラウザーが必要な理由は、暗号化・復号にWebCrypto APIを使っているから。
あと暗号化を全部メモリ上でやっているので、(1GB制限しなくても)あまり大きすぎるファイルはメモリ不足で扱えない。

Windowsなら「仮想メモリ」設定で「ページング ファイルなし」にしていない限り、
大きいファイルでも仮想メモリが使われるだけなので、メモリ不足で扱えないなんてことは起こりません。

暗号鍵とかそういう機密データがHDDやSSDにスワップするのはセキュリティ上好ましくないからといっても
Windowsは欠陥OSなのでアプリ側からスワップを回避するのは困難（というかOSのカーネルレベルを書き換えないと無理）です
だから、WebCrypto APIもスワップを完全

Re:

[Anonymous Coward]

Win32APIのVirtualLock()が機能しないケースがあるってこと？ 初めて聞いたしググっても出てこないな。
ソースあります？

Re:

[Anonymous Coward]

自己レス。 適切な解説 [microsoft.com]を見つけた。

• VirtualAlloc()ではできない。なぜならVirtualAlloc()はメモリ上に置かれることを保証するのではなく、スレッドのワーキングセットに置かれることを保証するものだから。そのため、スレッドが停止している場合はスワップされる可能性がある。
• データをメモリに置くことを保証したいのなら、AWE関数群 [microsoft.com]ならできるのでそっちを使え。AWE関数群はデータベース製品など、自分でメモリ管理を行いたいソフトウェア向けのAPIだ。
• ただしセキュリティの観点からは無意味。なぜならメモリ上にあってもReadProcessMemory()で他のプロセスからデータを読まれる

Re:メモリ不足でも「仮想メモリ」が使われるだけ

[Anonymous Coward]

非常に参考になった。
参考になるとか、素晴らしい洞察のモデをあげたいところだが、ACなのでモデ権がないのが残念でならない。