問題タブ [encryption-asymmetric]

SAML 2.0 で SAML 属性に対して対称暗号化を実行できますか? 非対称にできるようです。長所と短所は何ですか？

証明書を使用する以外に、公開秘密鍵の非対称暗号化を使用する方法はありますか?

パブリック/プライベート パーツは、マネージド .NET コードから簡単に生成できる必要があります。

私は RSA 暗号文c、公開鍵を持っています(e,n)。(ここでc = m^e mod n)

これで、プレーンテキストが または のmいずれ"1234XXX"か"12345XXX"である必要があることもわかりました。ここ"XXX"で、 は 3 桁の数字です。

3桁すべての数字をテストせずに、どれが正しいかを見つけることはできますか? "1234"(最初の部分がまたはであるかどうかを知りたいだけで、が"12345"何であるかは気にしませんXXX。)

私は、セキュリティで保護する必要があるクライアント側コード (具体的には js) を使用するアプリケーションを開発中です。つまり、ユーザーがコードを盗んで再利用できないようにするためです。コードを (暗号化で) 完全に保護する必要があるため、難読化はオプションではありません。js 暗号化を可能にするソリューションを求めてインターネットを広範囲に調査した結果、セキュリティを確保するために、この独自のコードはサーバー側でのみ実行できるという結論に達しました。

jsを使用してクライアントで実行できることをサーバーが処理する必要がなくなるような、他のアイデアや解決策はありますか。サーバー上でコードの一部を実行することはオプションですが、リソースは限られています。もう 1 つの問題は、「サーバー サイド js」のようなものにする必要があることです。つまり、ユーザー エクスペリエンスは変更されません。

これはこのサイトでの私の最初の質問であり、RSAの基本的な数学的理解しかありませんので、ご容赦ください。:)

私は大学での最終年度のプロジェクトのためにJavaWebアプリケーションを書いています。これは、聞いたことがある人のための安全な投票システムである「Pret-a-voter」のWebベースの実装です。

基本的に私の問題は、監査人の役割を果たす誰かを与えたいということです。

• ソースバイト配列（暗号化されるプレーンテキスト）
• RSA公開鍵ファイル
• 「宛先」バイト配列。これは、平文と公開鍵を指定して暗号データ​​を自分で計算した結果です。

次に、監査人が最初の2つの項目を使用して暗号化を実行できるようにし、3番目の項目が結果であることに満足してもらいたいと思います。したがって、暗号化を決定論的にする必要があります。つまり、同じ平文と公開鍵を使用した暗号化が繰り返されるたびに同じ暗号化データを生成する必要があります。

（注-このプロジェクトでは非常に小さなデータブロックを使用しています-対称暗号化はまったく含まれていません...これがRSAの「興味深い」使用法であることを認識しています！）

とにかく私はJavaでそれを見つけました

デフォルトのランダムパディングスキームを使用しますが、コストは11バイトです（したがって、2048ビットのキーペアを使用すると、2048 / 8-11 = 245バイトを暗号化できます）。同じ平文の暗号化を繰り返すと、異なる暗号文が生成されますが、これは明らかに私が望むECBモードではありません。

私の質問は-私は以下を使うべきですか？

多くの場所で、RSAはパディングなしでは安全ではないことを読みました。それは、攻撃者が平文/暗号文の辞書を作成できるからですか？これは、監査人が私の暗号化を検証できるようにするために必要な確定的暗号化の副作用であり、私のスキームでは監査人は信頼されているので、それで問題ありません。

私の質問のパート2は、よりJava関連です。上記のようにRSA/ECB / NoPaddingを使用する場合、（たとえば）長さ128のソースバイト配列（1024ビットRSAキーペアの場合）を提供し、それを暗号化して長さの別のバイト配列を取得できると思います128.次に、別の1024の長さの公開鍵を使用してそれを再度暗号化しようとすると、次のようになります。

javax.crypto.BadPaddingException：メッセージがモジュラスより大きい

誰かが理由を知っていますか？

編集-NoPaddingを使用した暗号化は、常にこの例外を生成するとは限りません-それは一時的なものです。ただし、暗号化によってこの例外が生成されない場合でも、復号化によって次の例外が生成されます。

javax.crypto.BadPaddingException：データはゼロで始まる必要があります

これを読んでくれてありがとう！どんな助けでも大歓迎です。

編集-申し訳ありませんが、私の元の質問は、私が何をしたいのかについてあまり明確ではなかったので、ここに[試み]の説明があります：

• 平文は選挙における有権者の投票です。
• Pret-a-voterは、投票者の機密保持などを犠牲にすることなく、エンドツーエンドで検証できるようにすることを目的としています。投票後、投票者には、投票が正しく記録されたことを確認するために使用できる領収書が提供されます。この領収書には、後で投票が改ざんされていないことが示されます。投票者は、領収書の情報をWebに投稿された同一のコピーと比較します。
• ただし、投票者がどのように投票したかを証明することはできません（強制につながる可能性があるため）。そのため、情報は平文ではなく、投票の暗号化されたコピーになります。
• 実際、平文は4回暗号化され、4つの異なる非対称キーが2つの異なるテラーによって保持され、それぞれが2つのキーを保持します。したがって、投票（平文）が公開鍵＃1を使用して暗号化する1人のテラーに提供され、次にその暗号文を2番目の公開鍵で暗号化し、その暗号文を2番目のテラーに提供します。仕方。結果の暗号文（4つの連続した暗号化の結果）は、Webに投稿されたものです（公開されます）。テラーは信頼されています。
• 暗号化された各投票は、中心が投票であり、暗号化のいくつかの層がある「タマネギ」として視覚化できます。投票するには、各レイヤーを順番に削除する必要があります。つまり、対応する秘密鍵（テラーが保持している）を逆の順序で適用する必要があります。これはセキュリティの鍵です。投票を復号化するには、すべての出納係が協力して作業する必要があります。
• Web掲示板は、5つの列を持つテーブルとして視覚化できます。最初の（左側）は完全に暗号化された投票（各投票者の領収書にも表示されます）を保持し、投票の段階で表示される唯一の列です。2番目の列には同じ投票のセットが含まれていますが、外層が削除されています。出納係2は、集計段階で秘密鍵を使用して投票を復号化することにより、この列と列3にデータを入力します。集計段階の最後に、列5には、集計できる完全に復号化された投票が含まれます。
• 各投票者は、列1の暗号化された投票にリンクする領収書を受け取ります。これは投票方法を示していませんが、選挙プロセス全体を通じて暗号化された投票を確認できるため、投票が改ざんされていないことを確認できます。 1列目にはそのまま残っています。もちろん、これは「エンドツーエンド検証」の半分にすぎません。投票者は、復号化が正しく行われたことを検証できないためです。つまり、投票から暗号化の外層を差し引いた列2にエントリがあります。 。各有権者は、列1のポイントまでの検証にのみ責任があります。
• その後、1列目のエントリが2列目に復号化されることを確認するのは監査人の責任です。これを行う方法は、確定的暗号化と、暗号化に使用される公開鍵が公開されていることに依存することです。
• 公開鍵は公開されているため、5列目から1列目まで単純に線を引いて、暗号化が繰り返されるときに誰かの投票に参加することは望ましくありません。つまり、暗号化された投票にあなたを結び付ける領収書は、実際にはあなたを暗号化されていない、読みやすい投票->強制！したがって、列1、3、および5のみが公開され（これが各テラーが2つの暗号化を実行する理由です）、列3の各エントリについて、{2,4}の対応するエントリの1つのみが監査人に公開されます。これにより、誰もが（監査人でさえ）暗号化された投票を暗号化されていない投票にリンクすることができなくなります。
• したがって、監査人は列3のエントリを取得し、列2の対応するエントリと公開鍵を与えられ、同じ暗号化を実行して、列2のエントリを実際に取得することを確認する必要があります。
• まとめると、これはエンドツーエンドの検証可能性を提供します。

申し訳ありませんが、それは非常に長かったです-決定論的な暗号化の必要性を説明していることを願っています。私は多くの基本的な詳細を見逃しました（私はこのスキームを大幅に変更しました）が、うまくいけば、コア原則がすべてそこにあります。読んでくれてありがとう-本当に感謝しています。

ウィキペディア（およびその他の情報源）によると、非対称暗号化は常に次のように機能します。

• パーティAには公開鍵と秘密鍵があります
• パーティBはAの公開鍵を使用して暗号化します
• パーティAは秘密鍵を使用してデータを復号化します

ただし、パーティAが自分のデータを暗号化できるようにしたくはなく、データを復号化できるようにしたいだけです。非対称ロジックを使用すると、次のようになります。

• パーティAには秘密鍵があります
• パーティBには秘密鍵（パーティAの公開鍵）があります
• パーティBは秘密鍵で暗号化します
• パーティAは秘密鍵を使用してデータを復号化します

これをある種のライセンス生成/チェックに使用します。クライアントはライセンスを生成しない場合がありますが、ライセンスファイルはクライアント側で読み取り可能である必要があります。

これはまだ非対称暗号化ですか、それとも別の方法を検討する必要がありますか？

.NET アプリケーションで同等のキーをプログラムで作成する必要があります...

makecert -r -pe -a sha1 -n "CN=MyName" -ss my -sr CurrentUser -sky exchange

makecert -r -pe -a sha1 -n "CN=MyName" -ss my -sr CurrentUser -sky signature

出力は最終的に次のように使用されます。

Isp アカウント ページを破棄することで、ユーザーが Isp プロバイダーから情報を簡単に取得できるようにする小さなアプリを開発しています。それを可能にするには、データベースにユーザー名とパスワードを保存する必要があります。パスワードを安全に保つために、openssl 公開鍵を使用してデータベースでエンコードし、秘密鍵を使用してデコードしてから、スクレイパーがアカウント ページにログインします。

誰かが私の Web サーバーのコントローラーを乗っ取ったとしても、パスワードが安全であるように、秘密鍵をどこに置くべきか疑問に思っていますか? Webサーバーに秘密鍵をそのままにしておくのはまったく不適切なので...

tks

R ロギング パッケージにセントリー ハンドラーを追加しています。現在、django-sentryは、安全なチャネルでクリア テキストで移動する共有キーに基づいて、クライアント (ログ レコードを送信するアプリケーション) を検証します。

R からの暗号化、できれば非対称の公開鍵ベースの暗号化が可能かどうか疑問に思っていましたが、関連するものは何も見つかりません。

「可能であれば」ではなく、「それを行う方法」と、誰かがすでにこれを行っているかどうか。

django-sentry の作成者とやり取りした後hmac、R パッケージ内に実装したを選択しましたdigest(バージョン 0.5+ に含まれています)。これは、「R を使用してデータを暗号化する方法」という質問には答え ませんが、私の最初の質問の基礎となった問題を解決します。

現時点では、私は R の非対称暗号化に積極的に取り組んでいませんが、それに興味があり、アイデアやコードに貢献したい場合は、ここにメモを残してください!

C＃で秘密鍵の暗号化を行う方法を探しています。

RSACryptoServiceProviderを使用できると思いましたが、公開鍵暗号化のみをサポートしています。

このテーマで私が見つけたのはこのプロジェクトだけでしたが、.netで見つけたものを使用したいと思います：http：//www.codeproject.com/KB/security/PrivateEncryption.aspx

私は署名を探していませんのでご注意ください。

非対称暗号化が必要であることに注意してください。

何か案は？

背景ストーリー：

アプリケーションを実行している別のシステムに暗号化されたファイルを送信しています。暗号化とは、ファイルを（多かれ少なかれ）変更したり、だれも閲覧したりできないようにすることです。アプリケーションは、公開鍵を使用してファイルを復号化し、それを使用して何かを実行できます。

ほとんどの人がアプリケーションから公開鍵を取得できることを私は知っていますが、この場合、これは問題ではありません。