安全でない (と思われる) 認証方式について - 186 @ hatenablog
Tomo’s HotLine:[P2P][DHT]ゼロ知識証明によるP2P認証方法の提案 前提や設定が書かれていないので詳しいことは言えないがコメント欄に書こうとしたら長くなったので, こっちで. 設定次第では何とかやりようはあると思う (本当に?) 記法が分かりづらい(ユーザーにAを使った上で, 数にもAを使っている)ので, 適当に書き直す. プロトコル ハッシュ関数が要るので書いておく. H:{0,1}^{2k+1}→{0,1}^{l(k)}, ただしl(k)は適当な整数値関数 (k辺りで良いか). 鍵生成 Pはp,q:k-bit safe primeを生成しn=pqとする. rを2k-bitの乱数とし, ID = H(n+r)とする. 認証 P,Vの共通入力をIDとする. Pへの補助入力を(n,r,p,q)とする. 追記: 共通入力は(ID,r), 補助入力は(n,r,p,q) Pは
[P2P][DHT]ゼロ知識証明によるP2P認証方法の提案 - Tomo’s HotLine
IT技術を中心に、暮らしに役立つ情報からクラシック音楽の解説まで気軽に情報発信しています。 WEBサイトはhttp://toremoro21.world.coocan.jp/ Twitterは@toremoro21です。 □はじめに セキュリティの興味深いトピックとしてゼロ知識証明というテクニックがある。 ゼロ知識証明 http://www.venture.nict.go.jp/series/cryptography/chapter2/2_4.html ゼロ知識証明は簡単に言うとつぎのようなものである。 [1]ユーザＡは大きな素数A,BよりC=Ａ×Ｂを作成する。 [2]ユーザＢはユーザＡとある通信をすることで、ユーザＡがＣの素因数分解ができるか否かを検証することができる。（それもユーザＡがユーザＢにＡ，Ｂの情報を提示せず！） 筆者はゼロ知識証明について昔から興味を頂き、この技術の応用を模索
![[P2P][DHT]ゼロ知識証明によるP2P認証方法の提案 - Tomo’s HotLine](https://cdn-ak-scissors.b.st-hatena.com/image/square/b4e38426fa9529bdb687a0c8ea1406a0f5bee683/height=288;version=1;width=512/http%3A%2F%2Ftoremoro.tea-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
ちょっと足りないMUAばかり - bonbonniere
ボンボニエール(bonbonniere)... フランス語で砂糖菓子を入れる小箱｡ このWeblogの中には甘いお菓子が入っているのでしょうか... （カテゴリやタグを選択することにより関連のある記事だけを選んで読むことが出来ます。） まともに全ての形式を扱えるMUAが少ないということが判った。少ないと言うか、今のところQMAIL3だけである。Sylpheed-Clawsは出来ることは多いが、それ以前にサーバーからメールを読み込めないし、1GB以上もメモリーを食ってしまって操作が出来なくなる。まったく実用性が無い。あれは評価用にビルドされているだけなのだろうか、、、、 信頼していたThunderbird+EnigmailもThunderbird本体のポリシー（文字コード処理に関する頑なな姿勢）と未解決のバグのせいで意外に接続性が悪いことが判った。 Eudora+EudoraGPG2.0はP
RSA署名の不味い実装の話らしい. - 186 @ hatenablog
[鏡] しっぽのさきっちょ 2006/08/29 暗号関連よりBleichenbacher's RSA signature forgery ASN.1based on implementation errorを読む. そのまま荒川氏が解説するんかなぁと思っていたら ふたつ目の記事は IETF OpenPGP WG のML からの話題。 RSA 署名においてアルゴリズムの実装の仕方によっては簡単に偽装ができてしまうというものらしいが，英語不得手なのでよく分からない。 とあって（；´Д｀）となったので適当に解説. SCIS2007で改良されたアタックが出ました. Bleichenbacherの攻撃法ではe=3かつセキュリティパラメータが3の倍数 (k=3072) の場合を考えています. e=17, 65537の場合や, セキュリティパラメータが3の倍数でない場合 (k=1024, 2048,
鍵長をどのように選択していくか ～等価安全性と鍵長の関係
鍵長をどのように選択していくか ～等価安全性と鍵長の関係：デファクトスタンダード暗号技術の大移行（5）（1/3 ページ） 暗号を選択するということは、計算手法となる「アルゴリズム」と安全性の上限を決める「鍵長（ハッシュ関数ならばハッシュ長）」の両方を決めるということである。このうち、アルゴリズムについては、本連載の第3回や第4回で紹介したようなアルゴリズムを中心に選択していけば、国際的なトレンドから見てもまず問題はないであろう。 残る問題は「鍵長（ハッシュ長）をどの程度に設定するか」である。鍵長を長くすることは、安全性の上限を高くする効果がある一方で、処理性能の低下につながることが多い。従って、必要な「安全性の上限」を確保しつつ、「処理性能の低下」を許容範囲内に抑えるようにすることが、鍵長を設定するうえで重要となる。 今回は、この安全性の上限と鍵長の関係について紹介したい。なお、安全性の上
「安全な鍵長の下限」とは — 旧メイン・ブログ | Baldanders.info
先日書いた 「暗号の危殆化と新しいアルゴリズム」 で署名・暗号に使う鍵の長さについて少しだけ言及しましたが， （私が断定的に書いてしまったのが悪いのかもしれませんが）その部分だけ注目している方もいるようです。 そこで今回は暗号鍵のサイズについてもう少し細かく見ていくことにしましょう。 暗号アルゴリズムの危殆化（compromise）要因には色々あるのですが， 大まかに以下の3つに集約できると思います。 （「将来の暗号技術に関する安全性要件調査」より引用） 暗号アルゴリズムの脆弱性（設計上の瑕疵など） 攻撃法の進歩（既存攻撃法の改良、新たな攻撃法の開発） 計算機性能の向上（解読計算能力の増大） 例えば前回紹介した SHA-1 への攻略法は上記の1番目の要因に相当します。 もし1番目および2番目の要因がないとするなら， 3番目の要因を取り除くためには鍵のビット長を大きくすればいいことに気がつき
cryptography
暗号のことを最初に知ったのは, 1980 年頃, 本屋で買った本 (文献 1) の『新種の暗号』を読んだときが最初です (RSA 暗号を紹介した記事です)。 これは勉強のために 読んだわけではなかったのですが どういうわけだか、その後色々な本で勉強するハメになりました。 最近ではインターネットで検索すると、 暗号に関連したページが随分たくさん出てきますが、 ほぼ大半が英文で書かれています。 そこで 英語を読むのが面倒くさいという人を対象にページを作ってみることにしました。 (但し、少し難しい話になってしまっているかもしれません。 その場合は悪しからず。) また暗号と言えば、暗号メールの PGP を思い出す人も多いと思います。 これに関してはインストール方法などを別のページで扱っています。 PGP -- 暗号ソフト マーチン・ガードナー (一松信訳), 数
これだけは知っておきたいアルゴリズム〜共通鍵暗号編 ― ＠IT
実際に運用中の情報システムで利用されている暗号アルゴリズムを移行することは、大規模なシステムであるほど、大変な労力とコストが必要となる。従って、規模が大きく、また長期運用が前提となっているシステムほど、暗号の選定には慎重になるべきである。 その意味で、「システム性能要求上問題がない範囲内であれば、現時点における最も高い安全性が確認されている暗号の中から選択するのが望ましい」というところに、暗号技術の2010年問題【注】の本質がある。いい換えれば、現在のデファクトスタンダードだからとの理由だけでその暗号を採用することは必ずしも勧められない。 【注：暗号技術の2010年問題とは】 米国は、現在利用されているすべての米国政府標準の暗号技術を2010年までにより安全な暗号技術へ交代させていく方針を明確に打ち出している。現在、世界中で使われているデファクトスタンダードの暗号技術は、そのほとんどすべて
Kazuho@Cybozu Labs: はてな認証 API の改善案
« Re: 攻撃してください→はてな認証の仮想セッション | メイン | 目指せバイナリアン (C-0.06) » 2006年05月11日 はてな認証 API の改善案 だんだん自分の中でも認証 API の問題が整理できてきたように思うので、改善案を書こうと思います。 まず、そもそも認証 API に何を期待するのか、という点について。 従来の各サイト毎にパスワードを入力する方式は、 ・パスワード管理が面倒 ・HTTPS じゃないので、パスワードがネットワーク上を平文で流れる ・メールアドレスが漏洩するかも (スパム襲来) といった不便さや懸念がありました。しかし、外部の認証 API を使用するウェブアプリケーションについては、これらの問題が解消できるはずです。具体的には、cookie がもれない限り安全な認証 API注1があればベストでしょう。 で、はてな認証 API は、以下の各点を修正
HMAC - Wikipedia
HMAC-SHA1の生成 HMAC (Hash-based Message Authentication Code または keyed-Hash Message Authentication Code) とは、メッセージ認証符号 (MAC; Message Authentication Code) の一つであり、秘密鍵とメッセージ（データ）とハッシュ関数をもとに計算される。 1997年2月、IBMのKrawczykらにより提唱され、RFC 2104として公開されている。また、FIPS PUB 198にも採用されている。 概要[編集] MACは認証及び改竄検出技術の核となるアルゴリズムである。HMACアルゴリズムは、MAC値（タグ）の算出に暗号学的ハッシュ関数を用いる。ハッシュ関数としては、SHA-2やSHA-3など任意の繰返し型ハッシュ関数を適用可能であり、ハッシュ関数Xを用いるHMACは
HMAC: Keyed-Hashing for Message Authentication
H. Krawczyk IBM M. Bellare UCSD R. Canetti IBM 1997年 2月 HMAC： メッセージ認証のための鍵付ハッシング (HMAC: Keyed-Hashing for Message Authentication) このメモの位置付け このメモは、インターネット・コミュニティに対して情報を提供するものである。このメモは、何らインターネットの標準を規定するものではない。このメモの配布に制限はない。 要旨 この文書では、暗号ハッシュ関数を使用してメッセージ認証を行なう仕組みである HMAC について記述する。HMAC は、MD5 や SHA-1 などの反復暗号ハッシュ関数を秘密の共有鍵と組み合わせて使用する。HMAC の暗号としての強度は、使用しているハッシュ関数のプロパティに依存する。 1.はじめに 信頼できないメディア上を伝送し、蓄積される情報の
Kazuho@Cybozu Labs: Hash ≠ MAC
« Re: はてな認証 API | メイン | 秘密鍵を後置している MAC の危険性 » 2006年05月07日 Hash ≠ MAC ハッシュ関数を MAC (メッセージ認証コード; いわゆる秘密鍵による署名) として使用していけません、という件について。 HMAC の論文を見たところ、様々な攻撃手法について述べてありました。ちなみに、今回のケースは、 Extension Attack です。引用すると、 Consider the "prepend-only" construction: MACk(x) = F(k, x) (i.e., the key k is prepended to the data x and the hash function - with the fixed IV - computed on the concatenated information). Be
Kazuho@Cybozu Labs: Re: はてな認証 API
« はてな認証 API | メイン | Hash ≠ MAC » 2006年05月06日 Re: はてな認証 API naoya さんありがとうございます、ということで、「認証APIのメモについてのレス」への返答です。 2006/5/7 追記: 1) で述べた MD5 による api_sig の偽装が可能であることを確認しました。この偽装を用いた攻撃は、auth.json および auth.xml については、1) に述べたとおり成功しません。認証リンクについては、仕様として任意のパラメータをハンドリングできる必要があるので、攻撃が成立してします (攻撃者がパラメータを追加することができる)。 よって、認証リンクの署名機能は壊れている、と言わざるを得ないように思います。 3) パラメータ指定の手法について 先にこちらから。 パラメータ指定は先日サポートしました。http://auth.ha
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Crypto++
NISTが次期ハッシュ関数選定のスケジュールを発表 | スラド
OpenPGP で利用可能なアルゴリズム一覧 — 旧メイン・ブログ | Baldanders.info
ドメインパーキング
『2015年刊行『暗号技術入門 第3版 秘密の国のアリス』』へのコメント
