4

C# で秘密鍵の暗号化を実行する方法はありますか?

の標準については知っていますRSACryptoServiceProviderがSystem.Security.Cryptography、これらのクラスは公開鍵の暗号化と秘密鍵の復号化のみを提供します。また、内部で秘密鍵暗号化を使用するデジタル署名機能を提供しますが、秘密鍵暗号化と公開鍵復号化を実行する公的にアクセス可能な機能はありません。

この種の暗号化を実行するための非常に良い出発点であるcodeproject でこの記事を見つけましたが、記事のコードは任意の長さのバイトをほとんど暗号化できないため、すぐに使用できるコードを探していましたランダムな値を含む配列(ゼロを含む任意の値を意味します)。

秘密鍵の暗号化を実行するための優れたコンポーネント (できれば無料) を知っていますか?
私は使用します.NET 3.5。

注: これは一般的に、非対称暗号化 (秘密鍵を使用して暗号化し、公開鍵を使用して復号化する) を使用する悪い方法と見なされていますが、そのように使用する必要があるだけです。

追加説明

あなたが持っていると考えてください 

var bytes = new byte[30] { /* ... */ };

2048bit RSAそして、誰もこの配列で何も変更していないことを確認するために使用したいと考えています。

通常、デジタル署名 (つまりRIPEMD160) を使用し、それを元のバイトに添付して受信者に送信します。

したがって、30 バイトの元のデータと、追加の 256 バイトのデジタル署名 ( であるため2048bit RSA) があり、全体で286 バイトになります。ただし、その256 バイトのうち実際にハッシュされるのは160 ビットのみであるため、正確に1888 ビット( 236 バイト) が未使用です。

だから、私の考えはこれでした：

元のデータの30 バイトを取得し、それにハッシュ ( 20 バイト) を添付して、これらの50 バイトを暗号化します。「デジタル署名内の実際のデータをプッシュできた」ため、 286バイトよりもはるかに短い256バイトの長さのメッセージが表示されます。

ECDSA リソース

MSDN
Eggheadcafe.com
c-plusplus.de
MSDN ブログ
Wiki

DSA リソース

CodeProject
MSDN 1
MSDN 2
MSDN 3

最終的解決

私がこの問題をどのように解決したかに興味がある場合は、さまざまなバージョンの Windows (およびそれ以降) で広くサポートされている1024bit DSAandを使用します。セキュリティは十分です (注文に署名していません。一部の子供が自分の iPhone で署名をクラックできないようにするため (:-D))、署名のサイズは40 バイトのみです。SHA1Windows 2000

4

4 に答える 4

3

あなたが設計しようとしているものは、「メッセージ回復を伴う署名スキーム」として知られています。

新しい署名スキームを設計するのは難しいです。メッセージ回復を使用して新しい署名スキームを設計することは困難です。あなたのデザインの詳細はわかりませんが、選択したメッセージ攻撃の影響を受けやすい可能性があります。

メッセージ回復を使用した署名方式の1つの提案は、RSAPSS-Rです。しかし残念ながら、この提案は特許でカバーされています。

IEEE P1363標準化グループは、かつてメッセージ回復を伴う署名スキームの追加について議論しました。ただし、この取り組みの現状についてはよくわかりませんが、チェックする価値があるかもしれません。

于 2010-07-24T09:31:52.387 に答える
2

公開鍵は秘密鍵のサブセットです。秘密鍵は、必要な完全な鍵のコンポーネントのみを使用するため、公開鍵として使用できます。

.NETでは、秘密鍵と公開鍵の両方がRSAParameters構造体に格納されます。構造体には、次のフィールドが含まれています。

  • D
  • DP
  • DQ
  • 指数
  • InverseQ
  • 係数
  • P
  • Q
于 2010-07-23T20:49:12.380 に答える
2

データが非常に小さいため、デジタル署名が比較して巨大な場合は、過剰な署名があります。解決策は、独自のアルゴリズムを展開することではなく、そこにあるものを削減することです。キーとハッシュをアマチュア的な方法で組み合わせようとするのは絶対に避けたいことです。これはすでに壊れているため、HMAC が存在します。

したがって、基本的な考え方は次のとおりです。

  1. 暗号的に強力な RNG を使用してセッション キーを作成します。

  2. PKE 経由で送信します。

  3. セッション キーを使用して、HMAC-SHA1 (または HMAC-RIPEMD160 など) を生成します。

  4. 与えられたデータに対してハッシュのサイズがとてつもなく大きい場合は、上部と下部を XOR して半分にします。必要に応じて繰り返します。

  5. データと (場合によってはカットダウンされた) ハッシュを送信します。

  6. 受信者は、データとセッション キーを使用してハッシュを再生成し、送信されたものと比較します (最初にハッシュを切り詰めた後)。

  7. セッション キーを頻繁に変更します。

これは、独自のシステムをローリングする狂気と、不適切なシステムを使用することの妥協点です。

私は建設的な批判に対して広くオープンです...

于 2010-07-23T23:10:02.223 に答える
1

コメントを読んだ後、私は今それを手に入れました。

答えは:やらないでください。

暗号化署名アルゴリズムは、手順を選択して選択 (または変更) できるアルゴリズムではありません。特に、署名sigが のように見えると仮定すると、 はと同じencrypt(hash)でorig + sigはありませんencrypt(orig + hash)。さらに、PKCS v1.5のような時代遅れの署名アルゴリズムでさえ、そもそもそれほど単純ではありませんencrypt(hash)。

あなたが説明したような手法は、賢さのためにセキュリティを犠牲にします。256 バイトの署名の帯域幅がない場合は、次のいずれかが必要です。

  1. 別のアルゴリズム、
  2. より広い帯域幅、または
  3. 小さめの鍵。

(1) を使用する場合は、自分で作成したアルゴリズムではないことを確認してください。単純な事実は、暗号が難しいということです。

于 2010-07-23T21:18:12.307 に答える