問題タブ [cryptography]

保存する前にパスワードを 2 回ハッシュすることは、1 回ハッシュすることよりも多かれ少なかれ安全ですか?

私が話しているのは、これを行うことです：

これだけの代わりに：

安全性が低い場合は、適切な説明 (またはリンク) を提供できますか?

また、使用するハッシュ関数によって違いはありますか? 同じハッシュ関数を繰り返す代わりに、(たとえば) md5 と sha1 を混ぜても違いはありますか?

注 1: 「ダブル ハッシュ」と言うときは、パスワードをよりわかりにくくするために、パスワードを 2 回ハッシュすることを指しています。衝突を解決するテクニックについて話しているのではありません。

注 2: 本当に安全にするには、ランダムなソルトを追加する必要があることはわかっています。問題は、同じアルゴリズムで 2 回ハッシュすることがハッシュに役立つか、それとも損なわれるかです。

Web アプリケーションの場合、シンプルで効果的なライセンス システムを作成したいと考えています。C# では、Reflector がインストールされていれば誰でも復号化メソッドを表示できるため、これは少し難しくなります。

かなり改ざん防止されているC#でファイルを暗号化する方法は何ですか?

OpenSSL によって生成された公開鍵を 1 つの NSS が理解できるものに変換するにはどうすればよいですか? OpenSSL でキーを生成し、それを pkcs12 形式にエクスポートし、NSS データベースにインポートしてから、McCoy ユーティリティで公開キーを抽出しました。そして、それは私の大きな驚きとは異なりました。それはおそらくエンコーディングの問題ですが、どちらを使用すればよいですか?

更新: OpenSSLには NSS キーが含まれているように見えるので、問題は、OpenSSL キーのどの部分が NSS キーでもあるかを調べる方法です。

2008 年 12 月 29 日の Dobb 博士の電子メール レポートで、暗号システムを設計するための新しい DSL (ドメイン固有言語) があることを見ました。これはCryptolと呼ばれ、Galois から入手できます。

誰かがそれを見ましたか？誰かがそれを使用する計画を持っていますか? 価値があると思いますか。

ロバート・ギャンブルは次のように述べています。

Cryptol は新しいものではなく、何年も前から存在しています。新しいのは、それ (の一部) が一般に公開されたことです。元々は NSA のために開発され、使用されていました。

ブライアンのように、クリプトルを使用する本当の理由はありません。SSL ベースの実装を (再) 検証する必要がある場合に役立つかもしれませんが、そこで役立つかどうかはわかりません (SSL ライブラリを検証する必要はありません。 (誤) SSL ライブラリの使用)。

セキュリティのためにすべてのユーザーに一意の PIN コードを割り当てる必要があるシステムの開発を検討しています。ユーザーは、自分自身を識別する手段としてのみ、この PIN コードを入力します。したがって、ユーザーが別のユーザーのピンコードを推測できるようにしたくありません。最大ユーザー数が 100000 であると仮定すると、この PIN コードはどのくらいの長さにする必要がありますか?

例: 1234 4532 3423

ある種のアルゴリズムを介してこのコードを生成する必要がありますか? または、ランダムに生成する必要がありますか？

基本的に、他の人のピンコードを推測できるようにしたくないので、十分な数のユーザーをサポートする必要があります。

私の質問が少し紛らわしいように聞こえる場合は申し訳ありませんが、疑問があれば喜んで明確にします.

どうもありがとうございます。

アップデート

以下のすべての投稿を読んだ後、さらに詳細を追加したいと思います。

1. 私が達成しようとしているのは、スクラッチ カードに非常に似たものです。
2. ユーザーにはカードが渡され、暗証番号を見つけるためにスクラッチする必要があります。
3. この PIN コードを使用すると、ユーザーは私のシステムにアクセスできる必要があります。

ユーザーがスクラッチ カードを使用するのを思いとどまらせてしまうため、追加のセキュリティ (ユーザー名とパスワードなど) を追加することはできません。制限内で PIN コードを推測するのをできるだけ難しくしたいと考えています。

素晴らしい回答をありがとうございました。

次の形式の楕円曲線がある場合:

この曲線上の点の数を計算する良いプログラムはありますか?

Schoof および Schoof-Elkies-Atkin (SEA) アルゴリズムについて読んだことがありますが、オープン ソースの実装を探しています。これを行うことができる良いプログラムを知っている人はいますか？

また、a が 1 で b が 0 の場合、j 不変量が 0 であるため、SEA アルゴリズムは使用できません。これは正しいですか?

アプリケーションを構築しており、データ転送を保護するために OpenSSL を使用する予定です。

クライアントにサーバーの証明書のみを検証させることを計画しています。サーバーの証明書を保護する方法について混乱しています。秘密鍵を含むサーバーの証明書を暗号化したいのですが、この暗号化にハードコードされた鍵を使用したくありません。

SSL を使用するアプリケーションが従う一般的な方法にはどのようなものがありますか?

ITAR 時代にさかのぼると、Diffie-Hellman 鍵交換を実行する人気のある sigがありました。

最新の DC では、これを次のようにかなり減らすことができます。

べき乗剰余コマンド ('|' は、効率的な指数倍増によって g^e % m を計算します) を使用した最新の dc 形式は、おそらくAPL以外では無敵ですが、元の形式を改善することはできますか? e と m の値は非常に大きくなることに注意してください。どちらも、暗号化セキュリティのためにそれぞれ 1024 ビットのオーダーになります。

パスワードへのソルトの目的を理解するのに苦労しています。主な用途は、レインボー テーブル アタックを妨害することだと理解しています。ただし、これを実装するために私が見た方法は、問題を実際に難しくしているようには見えません。

ソルトを次のように使用することを提案する多くのチュートリアルを見てきました。

これは、ハッシュが元のパスワードではなく、パスワードとソルトの組み合わせにマップされるようになったためです。しかし、$salt=fooと$password=bar言う$hash=3858f62230ac3c915f300c664312c63f。これで、レインボー テーブルを持つ誰かがハッシュを逆にして、入力 "foobar" を思いつくことができます。次に、パスワードのすべての組み合わせ (f、fo、foo、... oobar、obar、bar、ar、ar) を試すことができます。パスワードを取得するのにさらに数ミリ秒かかる場合がありますが、それ以外はそれほど時間はかかりません。

私が見た他の使用法は、私の Linux システムです。/etc/shadow では、ハッシュ化されたパスワードは実際にはソルトとともに保存されます。たとえば、"foo" のソルトと "bar" のパスワードは、次のようにハッシュされます$1$foo$te5SBM.7C25fFDu6bIRbX1。te5SBM.7C25fFDu6bIRbXハッカーがどうにかしてこのファイルを手に入れることができたとしても、の逆ハッシュには「foo」が含まれていることが知られているため、salt の目的はわかりません。

誰もがこれに当てることができる光をありがとう。

編集：助けてくれてありがとう。私が理解していることを要約すると、ソルトはハッシュ化されたパスワードをより複雑にするため、事前に計算されたレインボー テーブルに存在する可能性がはるかに低くなります。私が以前誤解していたのは、すべてのハッシュに対してレインボー テーブルが存在すると想定していたことです。