パスワード解析などに使われる「レインボーテーブル」の仕組みとは？
パスワードやアクセスキーなどの重要なデータは「ハッシュ関数」で一方向の変換を行うことで、漏えいの被害を最小限に抑えることができます。しかし、パスワードとハッシュ値の組み合わせを記録したレインボーテーブルによって、ハッシュ値からパスワードを解析される攻撃を受ける危険性もあります。そんなレインボーテーブルの仕組みについて、ソフトウェアエンジニアのKestas "Chris" Kuliukas氏が図解しています。 How Rainbow Tables work http://kestas.kuliukas.com/RainbowTables/ ハッシュ関数は文字列を別の文字列に変換することができる関数で、変換前の文字列から変換後の文字列を計算することはできますが、変換後の文字列から変換前の文字列を計算することはできません。変換前の文字列は「平文(Plaintexts)」、変換後の文字列は「ハッシ
QUICむけにAES-GCM実装を最適化した話 (1/2)
4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
