パスワード解析などに使われる「レインボーテーブル」の仕組みとは？
パスワードやアクセスキーなどの重要なデータは「ハッシュ関数」で一方向の変換を行うことで、漏えいの被害を最小限に抑えることができます。しかし、パスワードとハッシュ値の組み合わせを記録したレインボーテーブルによって、ハッシュ値からパスワードを解析される攻撃を受ける危険性もあります。そんなレインボーテーブルの仕組みについて、ソフトウェアエンジニアのKestas "Chris" Kuliukas氏が図解しています。 How Rainbow Tables work http://kestas.kuliukas.com/RainbowTables/ ハッシュ関数は文字列を別の文字列に変換することができる関数で、変換前の文字列から変換後の文字列を計算することはできますが、変換後の文字列から変換前の文字列を計算することはできません。変換前の文字列は「平文(Plaintexts)」、変換後の文字列は「ハッシ
「RFC7525: TLSを安全に使うための推奨事項」の改定 - ASnoKaze blog
様々な組織や団体がTLSを安全に利用するためのドキュメントを出してたりする。 IETFでも2015年にRFC7525 「Recommendations for Secure Use of TLS and DTLS」として、使用する上での推奨事項をまとめている。 それについての詳細は、urushima先生の記事を見ていただくと良いと思う。 blog.livedoor.jp 上記のRFC7525から5年が経ち、その間にRFC 8446 TLS1.3の発行などもありました。そのため、IETFではこのRFC7525の改定作業が開始されました RFC7525bis IETFのUTA (Using TLS in Applications) WGでは、RFC7525の改訂版として、次のドキュメントをすでにWG Itemとして扱っている draft-ietf-uta-rfc7525bis ここでは、簡単に
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ページを開く
