1

毎回異なるランダムな素材を前に付けて、同じ整数を繰り返し暗号化することを安全に許可する暗号化スキームはありますか? 湯に浸かりそうな手術のようです。

Web アプリケーションでのアイテムのスパイダリングを防止したいが、永続的なアイテム ID/URL を保持して、コンテンツ リンクが期限切れにならないようにしたい。これに対する私のセキュリティ要件はそれほど高くありませんが、秘密を明らかに侵害する完全にばかげたことはしたくありません。

// performed on each ID before transmitting item search results to the client
public int64 encryptWithRandomPadding(int32 id) {
    int32 randomPadding = getNextRandomInt32();
    return encrypt(((int64)randomPadding << 32) + id), SECRET);
}

// performed on an encrypted/padded ID for which the client requests details
public int32 decryptAndRemoveRandomPadding(int64 idToDecrypt) {
    int64 idWithPadding = decrypt(idToDecrypt, SECRET);
    return (int32)idWithPadding;
}

static readonly string SECRET = "thesecret";

生成された ID/URL は永続的であり、暗号化された ID はまばらに読み込まれます (uint32.Max の 1 未満は一意であり、既存の推測の可能性を減らすために別の一定のパディングを追加できます)、クライアントは同じ検索を実行し、毎回異なる代表 ID で同じ結果が得られます。露骨な暗号化の問題がない限り、それは私の要件を満たしていると思います。

例：

 encrypt(rndA + item1)   -> tokenA
 encrypt(rndB + item1)   -> tokenB
 encrypt(rndC + item2)   -> tokenC
 encrypt(rndD + item175) -> tokenD

ここでは、tokenA と tokenB の両方が同じ項目を指していることを識別する方法はありません。これにより、スパイダーが重複した検索結果を取得せずに削除するのを防ぎます (取得すると使用量メーターが増加します)。さらに、item2 が存在しない場合があります。

検索を再実行すると、同じシークレットで複数の方法が埋め込まれた同じ int32 が返されることがわかっている場合、一般的な暗号アルゴリズムでこれを安全に実行できますか? ありがとう、暗号の専門家！

注：これは、私が望んでいたようにうまくいかなかった質問へのフォローアップです：シークレットと共有ソルトで整数を暗号化する

4

1 に答える 1

2

暗号化が安全である場合、ランダムなパディングによって解読が容易になることも困難になることもありません。これほど短い、1 ブロックの長さのメッセージの場合、すべてが侵害されているか、何も侵害されていないかのどちらかです。ストリーム暗号を使用しても、さらに先に進むには鍵が必要です。優れた暗号化のポイントは、余分なランダム性を必要としないことです。ゼロ パディングやその他の既知のメッセージの先頭に少なくとも 1 ブロックの長さがあることは、可能であれば明らかに回避する必要がありますが、それはここでは問題ではありません。それは純粋なノイズであり、誰かがそれを発見すると、スキップしてそこからクラックを開始します。

現在、ストリーム暗号では、最初にすべてのランダム性を追加でき、後のバイトは同じキーで同じままです。それを忘れないでください。これは実際にはブロック暗号に対してまったく何もしません。それ以外の場合は、ランダムなビットを実際の値に xor して、それを利用する必要があります。

ただし、MAC をパディングとして使用した方がよい場合があります。適切な暗号化を使用すると、暗号化された mac から情報が漏えいすることはありませんが、半ランダムに見えるため、暗号化中にエラーや悪意のある攻撃がなかったことを確認するために使用できます。復号化。任意のハッシュ関数は、単純な CRC-32 であっても、暗号化後に何も提供せずに MAC を作成できます。

（暗号学者は、関連性のために少しか2つ削る方法を見つけるかもしれませんが、事前にそれらがどのように関連しているかを知っていれば、大量の平文になりますが、それはまだ実用的ではありません. ）

前に質問したように、すべてのメッセージの前に暗号化されていないソルトを安全に挿入できます。ソルトが暗号化された値を危険にさらすことができるのは、実装が壊れているか、キーが危険にさらされている場合のみです。ソルトがキーに適切に混合されている限り、特に復号化の前に拡張されたキー スケジュールにソルトを混合できる場合に限ります。多くのビットを使用する最新のハッシュ アルゴリズムは非常に優れていますが、通常の入力キーに混合しても、常にキーのみと同じセキュリティが得られます。

于 2012-07-29T04:52:51.330 に答える