共有秘密を使用して認証済みHTTPサービスエンドポイントを作成しようとしています。共有秘密鍵の長さ
良い例はFlickr signing schemeです。
ベスト・パブリック・キーと秘密鍵の長さは何ですか？私は、人々が恣意的に言うとほとんど確信していますが、何が一般的な意見であるのか、またその理由を知りたいと思います。
もう1つの質問ですが、FlickrはMD5を使用して「署名」を生成します。私はMD5はもはや安全ではないと読んで、MD5の代替品は何ですか？また、サービスの消費者はこのシグネチャを生成する必要があるため、使いやすさとマルチプラットフォームのライブラリサポートのためのボーナスポイントが必要になります。
-
また、そのtentative timeline of development of New Hash Functions
NIST cryptographic hash projectと
で別の最近の議論を見て？もし誰かがブルートフォースで鍵を握ったらどうなりますか？本当に心配しているのであれば、なぜクライアント側の証明書でSSLを使用していないのですか？
これらは、暗号化に最適な方法を決定する前に、特定のプロジェクトに答える必要のある一般的な質問です。
ケーススタディ：私が開発しているアプリケーションでは、DES（yes、plain DES）を使用してキーデータを暗号化（ハッシュではなく）し、復号化します。すべてのURLは、共有キーを保持するサーバーによって生成される必要があります。 URLの有効期限を制限するオプションのタイムスタンプがあります。期限切れのURLでサービスにアクセスすると、403のバックを取得します。問題のデータは比較的低価格であり、暗号化が壊れても受託者は考慮しません。
民生機器で壊れる可能性がありますか？確かに。
それを破ることに高い利益がありますか？どういたしまして。
なぜデータを平文で送信しないのですか？私たちは何らかのレベルのコントロールを確保したいからです。私の主な目標は、スクリプトの児童が一定の挿入/更新でサービス拒否攻撃を作成しないようにすることです。
なお、平文のデータは、クライアントとサーバー間の通信のどこにも現れません。つまり、誰かが無差別にキーを押しても、キーを壊したことを知るために何らかのヒューリスティックを適用しなければならないということです。あいまいさによるセキュリティ、はい、時にはあいまいさが有益です。
MD5の代替案については、SHA family of hash functionsが事実上の置き換えと見なされていると思います。 SHA512は明らかに（長いハッシュ付き）新しいバージョンは、より多くのセキュリティを提供します
共有キーの長さを選択する場合、可能なキーのスペースを確保するために、ハッシュ値の長さと同じ長さになるようにします。長いキーを選ぶと、それ以上のメリットはないようです。理論的には、可能な限り多くのキーを試してみたときに、ハッシュ値があると理論的に見ていました。 （免責事項：私は暗号専門家ではなく、前の声明で間違っているかもしれません）。
今日、SHAは.NETやJavaを含むほとんどのプラットフォームでサポートされています。
SHA1はほとんど壊れています。それを使用しないでください。 –
@ペドロ;私はそれがアプリケーションに依存していると言いますが、もちろん可能ならば、新しいハッシュ関数の1つを選択するべきです。 Schneierの記事を引用するには_「2^69計算でSHA-1の衝突がブルートフォースよりも約2,000倍速いことがわかりました。現在、これは現行技術の実現可能性のほんの端です。 2^69の計算は "一般的なWebアプリケーション"に対してかなり安全です。オンラインバンキングサイトを開発している場合は、おそらくSHA1を使用しないでください:-) – driis
MD5の代替品は、MD6 Hash Algorithmでもit is not ready yetです。
一方、ここにはa good read on secure hashing from Bruce Schneierがあります。あなたのサービスをする必要がどのように安全なSHA-3 Second Round Candidates Released、2009年7月
ポインタの良いリスト。 MD6はSHA-3大会に提出されましたが、第2ラウンドに選ばれなかったので、MD6は私の最初の選択ではありません。 もちろん、Bruce Schneiersのブログは偏っています。 – Accipitridae
鍵サイズを選択するときは、NIST Special Publication 800‑57 (Part 1)、§5.6が参考になります。クレジットカード業界の勧告は、「強力な」セキュリティのためのものであり、私は112ビットのセキュリティのビット以上と解釈します。 NISTのガイドラインは、対称暗号の場合はトリプルDES（または128ビットAESまでの小さなバンプ）、RSAの場合は2048ビットのキーに対応することを示しています。大体の同等性については、表2を参照してください。
ハッシュアルゴリズムの場合は、アプリケーションによって異なります。広く展開されている暗号化アプリケーションとの相互運用性が必要ない場合は、SHA-224以上を使用してください。しかし、場合によっては、衝突攻撃に対する新たな脆弱性にもかかわらず、相互運用性にはSHA-1が必要な場合があります。
Flickr署名方式が完全に壊れています。それを絶対に使用しないでください。
http://netifera.com/research/flickr_api_signature_forgery.pdf
OMG、Flickrはほとんどすべての間違いをしています。この勧告は本当に役に立ちます。 – Accipitridae
DESの使用を推奨するのは悪いアドバイスです。セキュリティが最優先事項ではない場合でも、依然として受け入れられている標準（たとえばAES）を選択したいと考えています。 AESの実装は通常DESよりも高速であるため、弱い暗号化を使用することで何も得られません。しかし、潜在的な休憩からあなたのスキームのセキュリティを絶えず再評価しなければなりません。 AESのような強力なアルゴリズムを使用すると、設計と分析が簡単になります。そしてシンプルさは確かにあなたが最優先ではない何かのためにしたいものです。 – Accipitridae
私の推奨は、OPが自分のセキュリティニーズを評価し、特定の技術を使用するのではなく、適切なものを選ぶことでした。しかし、ねえ、downvoteのおかげで。 – kdgregory
-1もあります。これはちょうど悪いアドバイスです。最高レベルのセキュリティを使用することには欠点はありません。他に何もない場合は、より高いセキュリティが必要なプロジェクトでも機能するAPIを使用する方法を学びます。 – necromancer