AES-256 GCMに渡すkeyに、パスワードそのものではなく、鍵導出関数（PBKDF2など）で生成したハッシュ値を指定する理由は？
以前書いた、「あるデータをパスフレーズで暗号化し、公開ストレージ（URLが判明すれば誰でも読み取り可能）に暗号化ファイルの形式で保存し（期間は無期限）、あとからパスフレーズで復号して読み取るためのコード」を改修するため、「AES-256 GCM、または、ChaCha20-Poly1305を用いて、データを1つのパスフレーズを用いて暗号化するライブラリ」をTypeScriptで書こうと考えています。 この場合の要件は： 暗号化したデータは、第三者が自由に読み取り可能であり、その場合でも安全性を保つ必要がある 暗号化したデータは、無期限で利用される場合がある。したがって、短期間のみ用いるものではない 暗号化したデータには、パスフレーズを除く、復号に必要な情報がすべて含まれる。暗号化と複合に必要な秘密情報はパスフレーズのみ になります。例えるなら、Gitリポジトリ内で特定のファイルを暗号化するよ
Adobeサイトから漏えいした暗号化パスワードはなぜ解読されたか
Adobe社のサイトの不正アクセス（参照、参照）によって、少なくとも3800万人のIDと暗号化されたパスワードが漏えいしたと言われています。既に報告したように、私のアカウントも漏えいしていました。 その後、『Adobeの情報流出で判明した安易なパスワードの実態、190万人が「123456」使用』というニュースが流れてきました。安易なパスワードが使われている統計は今までもあり、「パスワードの実態」に関しては「そんなものだろうな」と思いましたが、問題は、どうやって「暗号化パスワード」を解読したかです。 別の報道では、Adobeサイトがパスワードの暗号化に用いていたアルゴリズムはトリプルDESだったということです。トリプルDESは電子政府推奨暗号リストの今年の改訂でもしぶとく生き残り広く使われている暗号化アルゴリズムです。そんなに簡単に解読されたのでは問題ですが、実際には、「トリプルDESが解読
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
