暗号と署名の話 - 186 @ hatenablog
某身分の義務であるアウトリーチ活動の一環として, 教科書的RSA暗号/署名と教科書的ElGamal暗号/署名を比べてみます. 以下の図をご参照ください. 追記: 絵だけみてもわからないので, 書き直し. RSA暗号は知っているが, ElGamal暗号やElGamal署名については良く知らないという人向けです. 承前 高木浩光＠自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんとで問題になっている点は以下です. 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日本ベリサイン株式会社による公開鍵暗号方式の解説 (略:186) 「公開鍵暗号方式による署名は、メッセージダイジェストを秘密鍵で暗号化することで実現する。」 事例2:
鍵生成には暗号論的に安全な乱数を使おう
SSHの鍵生成には暗号論的に安全な疑似乱数を使おうという話。 暗号論的に安全ではない疑似乱数がどれだけ危険かというのを、簡単なCTFを解くことで検証してみました。 背景 SSH公開鍵に自分の好きな文字列を入れる、という記事を読みました。 かっこいいSSH鍵が欲しい 例えばこのSSH公開鍵、末尾に私の名前(akiym)が入っています。 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFC90x6FIu8iKzJzvGOYOn2WIrCPTbUYOE+eGi/akiym そんなかっこいいssh鍵が欲しいと思いませんか？ かっこいい！真似してみたい！ そこまではいいんですが、問題は実装です。 秘密鍵を生成する際の乱数生成には高速化のために Goのmath/randを使っていますが、乱数が用いられるのは公開しない秘密鍵自体であり、このアルゴリズム自体はLagged Fib
HTTPSは安全なのか？ - Qiita
いきなり追記 2024-01-09 この記事にはまともな結論がありませんし論点も定まっていません この記事には批判が多いので、こちらの素敵な記事をぜひお読みください。 Free Wi-Fi(00000JAPAN)は安全なのか？ コメントで不愉快とされたところを削除しました。 徳丸さんのツイート 猫の写真 素人というエクスキューズ （編集履歴はqiitaの機能で見れると思います） 信頼できるサービスであれば Free Wi-Fi に限らず被害に遭う可能性はとても低いと思います。気にせず使ってください。 気分を害された方にお詫び申し上げます。 ここから元記事 お正月休みは卒業した大学の記事を書く予定でしたが、ちまたで話題の「httpsなら安全」について攻撃的なツイートを散見どころかめっちゃ見たのでこの記事を書いています。httpsを盲信されるならまだしも、無知の斧で攻撃を振るう方に悲しみを覚え
ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
HPKE とは何か | blog.jxck.io
Intro HPKE (Hybrid Public Key Encryption) が RFC 9180 として公開された。 RFC 9180: Hybrid Public Key Encryption https://www.rfc-editor.org/rfc/rfc9180.html HPKE は、公開鍵暗号方式と共通鍵暗号方式を組み合わせて(ハイブリッド)任意の平文を暗号化するための、汎用的な枠組みとして標準化されている。 この仕様は、多くのユースケースが想定されており、 RFC になる前から ECH (Encrypted Client Hello), MLS (Message Layer Security), OHTTP (Oblivious HTTP) など、さまざまな仕様から採用を検討されている。 本サイトで書く予定の他の記事でも HPKE は頻出する予定であり、今後より多く
Private information retrieval using homomorphic encryption (explained from scratch)
Private information retrieval using homomorphic encryption (explained from scratch) September 18, 2022 · 28 minutes This is a from-scratch explanation of private information retrieval built using homomorphic encryption. I try to assume only a general math / computer science background. To simplify things, my explanations may not always match academic definitions. You can check out this password br
イラストで正しく理解するTLS 1.3の暗号技術
イラストで正しく理解するTLS 1.3の暗号技術 初めに ここではTLS 1.3（以下TLSと略記）で使われている暗号技術を解説します。 主眼はTLSのプロトコルではなく、「暗号技術」の用語の挙動（何を入力して何を出力するのか）と目的の理解です。 実際にどのような方式なのかといった、より詳しい説明は拙著『図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』（暗認本）や『暗認本』の内容を紹介したスライドや動画などの資料集をごらんください。 なお表題の「イラストで」は数式を使わないという程度の意味です。 TLSで守りたいもの TLSはコンピュータ同士が安全に通信するための規格です。 主に人がブラウザを介して「https://」で始まるWebサイトにアクセスするときに利用されます。 安全に通信するためには、通信内容が盗聴されても情報が漏れない機密性が必要です。 それから通信が改
セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
画像出典: 書籍...記事中に掲載した販売ページ / Webサイト...スクリーンショット はじめに こんにちは。株式会社Flatt Securityの @toyojuni です。 突然ですが、弊社Flatt Securityは「開発者に寄り添ったセキュリティ」を標榜しています。Webアプリケーションなどに脆弱性がないか調査する 「セキュリティ診断」 においても、セキュアコーディング学習プラットフォーム 「KENRO」 においても、いかに開発者フレンドリーなサービスを提供できるかという点を大事にしています。 そんな弊社はお客様からさまざまな開発におけるセキュリティのアドバイスを求められることも多いのですが、その中で「開発に役に立つセキュリティ」という切り口では、なかなかまとまっているリファレンス集がないという課題に気付かされました。 そこで、社内でアンケートを実施して「開発者にオススメのセ
NFTに対する技術的な誤解
はじめに 「メタバース上の土地は買うべきか」から始まり、NFTの価値は信仰によるものであるとの一連の流れを読み大変感銘を受けた。 kumagiさんのNFTの価値は信仰によるものであるとの指摘も、sasakiさんの自分の興味からNFTを買った話も、どちらも私個人としては理解できる話であった。 一連の議論のリンクは貼っておくので、詳しく知りたい方は見てほしい。 NFTとメタバースについて思うこと 空想のNFTと現実のNFT Re: 空想のNFTと現実のNFT Re: Re: 空想のNFTと現実のNFT Re: Re: Re: 空想のNFTと現実のNFT さて、これらの議論に対するtwitterをはじめとするSNSのコメントを見ると、技術的に誤った情報の配布や誤解を生みかねない表現を使ってNFTの価値について語っている人が想像以上に多く感じた。 ブロックチェーンやNFTは新しい技術分野であるため
あなたの「公開鍵暗号」はPKE? それともPKC? - Cybozu Inside Out | サイボウズエンジニアのブログ
初めに サイボウズ・ラボの光成です。 いきなりですがクイズです。次のうち正しい説明はどれでしょう。 SSHやFIDO2などの公開鍵認証はチャレンジを秘密鍵で暗号化し、公開鍵で復号して認証する。 ビットコインでは相手の公開鍵を用いてハッシュ値を暗号化して相手に送る。 TLS1.3ではサーバ公開鍵を用いてAESの秘密鍵を暗号化する。 答えはどれも間違いです。 公開鍵認証は、(デジタル)署名を使って相手先の正しさを検証するものであり、暗号化は行われません。 同様にビットコインもデータや相手の正当性を確認するために署名が用いられ、暗号化は行われません。 TLS 1.3ではRSA暗号の公開鍵を用いて暗号化する方式(static RSA)は廃止され、ECDH鍵共有された値を元に秘密鍵を生成し、AES-GCMなどの認証つき暗号で暗号化します。 公開鍵暗号とは いわゆる公開鍵暗号には大きく2種類の意味があ
Implementing RSA in Python from Scratch
Implementing RSA in Python from Scratch This is a guide to implementing RSA encryption in python from scratch. The article goes over the math and has code examples. Please note that it is essential for me to emphasize that the code and techniques presented here are intended solely for educational purposes and should never be employed in real-world applications without careful consideration and exp
Understanding Zero-knowledge proofs through simple examples
I recently listened to this ZKFM podcast, which gave practical examples that clearly explained key concepts in zero knowledge. I felt inspired to transcribe them here. In cryptography, zero knowledge proofs let you convince me that you know something, or have done something, without revealing to me what your secret thing was. Practically, zero-knowledge is important because it gives you privacy in
タイムスタンプの再発見と「いわゆるブロックチェーン」
（第三者）検証可能な形で情報の非改ざんを保証することブロックチェーン技術の登場により、「情報が改ざんされずに検証できる形で残る」という機能が注目を集めている。しかし、ブロックチェーン技術の文脈でこの機能との関係を考える時に、多くの議論において技術史を踏まえない曖昧な議論が散見され、これが様々な場面で無用なディベートを生み出しているように見られる。そこで、この機能についての歴史を紐解きながら、「いわゆるブロックチェーン」をどう理解したらいいのかを述べたい。 この節のタイトルのように、第三者検証可能な形で情報の非改ざんを保証すること、という要請はもちろん古くから存在する。その多くは、信頼される第三者機関が、ある時点で文書が存在したことを証明するというもので、日本では法務省が所轄する公証制度が存在する[1]。[1]では、公証制度のことを以下のように書いている。 公証制度とは，国民の私的な法律紛争
食事する暗号学者の問題 - Wikipedia
食事する暗号学者の問題[1] (dining cryptographers problem)とは、匿名による情報発信法やその匿名性の証明に関する問題である。 問題[編集] 3人以上の暗号学者達が円卓で食事を取っていた。 そこにウェイターがやって来て匿名の何者かが彼ら全員分の食事代を支払ったと学者達に伝えた。学者のうちの誰かが払ったのかもしれないし、学者達の雇い主であるNSA(アメリカ国家安全保障局)が支払ったのかもしれない。どちらが支払ったのか知りたいが、もし学者のうちの誰かが支払ったのなら、匿名で支払ったという意思を尊重したい。 どちらが支払ったのか、支払った学者を特定することなく知る方法はあるだろうか？ 解決法: 食事する暗号学者のプロトコル[編集] 例として4人の場合を考える。 まず右隣りの学者との間で、メニューの裏でこっそりコインをトスする。 結果は2人だけで共有し、他の学者には秘
scryptがGPUに破られる時 | びりあるの研究ノート
一般的によく知られている SHA-256 や MD5 などのハッシュ関数は非常に単純な設計となっており、非力なパソコンや組み込み機器、スマフォなどでも高速に計算できます。 しかしながらその一方で、ハッシュ関数を手当たり次第に計算し、もとの入力値を復元するいわゆる「ブルートフォース攻撃」が容易であるというデメリットがあります。 特にこのような SHA-256 や MD5 といったハッシュ関数は、GPU を用いるか、もしくは専用のハードウェア (FPGA もしくは ASIC) を製作することで非常に高い効率で計算（攻撃）ができてしまうことが知られています。 そのため、GPU ないし専用ハードウェアを用いたとしても、攻撃効率の改善が難しくなるような新たなハッシュ関数がいくつか提案されています。 その中で比較的古く (2012年ごろ) に開発され、他のハッシュ関数にも影響を与えている「scrypt
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
（調査中）