少量のデータに署名する（そしてその署名を同様の小さなスペースに保存する）必要があります。標準のPKCS署名は大きすぎるため、8〜16バイトの署名の領域に何かが必要です。第二に、非対称暗号である必要があり、第三に、比較的安全である必要があります（今日のコンピューターでは5分で壊れることはありません）。
私は望んでいた：
ただし、RSA暗号化を使用すると、RSAはキーの最小値と同じ長さの出力を生成します。したがって、512RSAキーは64バイトのデータを生成します。他にどのようなオプションがありますか？
編集：非対称暗号とは、共有秘密を持つことができないことを意味します。つまり、1つの秘密を持つ署名「サーバー」と、データがその発信元からのものであることを確認する必要がある分散パブリックアプリケーションがありますしたがって、署名の秘密を含めることはできません。
Let's assume that the message M you want to store can be split into two segments: M1 and M2, and that M = M1||M2.
In general, the verification step in a message recovery scheme will tell you if M is authentic, but it will also give you back one segment (for instance M2) so that you effectively need to store only the other segment (for instance M1). As a drawback, you cannot access M2 without verifying the signature first, but in most cases that is really not what one wants to do.
Intuitively, some storage can be used for both a part of the message and a part of the signature.
The most widespread example is probably the scheme standardized into ISO 9796-2 (which is not totally secure! Read below...). In that scheme, a 2048 bit RSA signature coupled to SHA-1 can be used to store 234 bytes of M2. In practice, that means that the signature length varies from 20 to 256 bytes, depedening on the length of M.
More specifically, if n is the length of your RSA key and h is the length of the hash output (both in bits), the number of bytes you can store in the signature is (n-h-16)/8.
Whether it is good or not for you depends on how long your data is.
The caveat I mention above is that Coron, Naccahe, Tibouchi, and Weinmann recently showed that ISO 9796-2 can be broken more easily that one would expect, even though not "in 5 minutes on one computer" (they had to resort on several EC2 instances). Yet, it may be good enough for you security wise.
Other message recovery schemes exist, but one thing you should pay attention to is their patent status. For instance, PSS-R, Naccache-Stern, Nyberg-Rueppel, Pintsov-Vanstone cannot be freely used.
DSA is a possibility. In this case, the signature does not embed any part of the original message. The general rule is that if you want a security of s bits, you need a 4s bit long DSA signature. To say, for 80 bit security (equivalent to 2TDES) you need 40 bytes. The same formula applies for ECDSA, but DSA is simpler and more widespread in software libraries.
In both cases (DSA and ECDSA), the signing server must have a good source of randomness. If the random generator is not reliable (e.g. if the server is a Virtual Machine or an embedded system), DSA and ECDSA could be broken, no matter how long the signatures are.
私はあなたの要件が得られるとは思わない。取得できる最も近いものは、おそらく楕円曲線を使用する場合ですが、それでも、たとえば192/8 * 2=48バイト以上の出力が得られます。160ビットの曲線を使用すると、40バイトまで下げることができますが、その後はセキュリティマージンが低くなりすぎます。この答えは前にポイント圧縮について述べましたが、それはおそらく使用できません。
CRCなどの非セキュアハッシュを使用する代わりに、セキュアハッシュを使用してから最初のXビットのみを使用する方がはるかに優れています。ECC 160ビットの場合、SHA-1が当然の選択です。このようなデータの小さな部分では、SHA-1は十分に強力です。安全なハッシュの考え方は、同じハッシュにマップする別のメッセージを誰も作成できないということです。これは、CRCやAdlerなどの関数のプロパティではありません。
あなたの要件は自己矛盾しています。
少量のデータに署名する
おそらく安全なダイジェスト（ハッシュ）
非対称暗号である必要があります
しかし、これは可逆的であるため、安全なダイジェストではありません。
ただし、RSA暗号化を使用すると、RSAはキーの最小値と同じ長さの出力を生成します
リバーシブルの暗号化を使用すると、キーの最小値と同じ長さの出力が生成されます。
ハッシュのみが必要な場合は、ソルトされたmd5（16バイト）を使用します。