暗号化署名の代替
開発中のプログラムがあり、現在ed25519を使用してメッセージに暗号で署名しています。ただし、これらの署名でさえも、私が望むよりも長くなっています（64バイト+メッセージ）。
署名しているメッセージはシステム内から生成されます（つまり、プログラム内のメッセージを生成して、さまざまなサーバー/ノードで署名しています）。
メッセージを（強力な暗号で）暗号化する代わりに、署名のオーバーヘッドを制限するとどうなりますか？
メッセージは現在72ビットの長さです（現在は比較的少数のメッセージの衝突を制限するため）、それを104ビット程度に増やし、それにソルトを追加することを考えています（どれくらいの時間が許容できるかわかりません）。 salt +メッセージを暗号化します。次に、受信ノードでメッセージを復号化し、ソルトを検証します（そのため、許容できる長さである必要があります）。
私の全体的な目標は、メッセージが有効であることを確認し、両方のエンドポイントを自分の制御下に置いて、可能な限り最小のオーバーヘッドでメッセージ（メッセージが表示されていてもいなくても構いません）を取得できるようにすることですが、通信は常にステートレスで簡単に変更できます第三者による。
私の全体的な目標は、メッセージが有効であることを確認し、両方のエンドポイントを自分の制御下に置いて、可能な限り最小のオーバーヘッドでメッセージ（メッセージが表示されていてもいなくても構いません）を取得できるようにすることですが、通信は常にステートレスで簡単に変更できます第三者による。
「[メッセージが表示される]かどうかは問題ではない」ため、暗号化は必要ないようです。むしろ、メッセージの整合性チェックが必要なだけのようです。
したがって、暗号化する代わりに、プレーンテキストメッセージに付加されるメッセージ認証コード（MAC）を使用できます。ただし、攻撃者によるMACの改ざんを回避するために、両方のエンドポイントで共有秘密鍵が必要です。この場合、キーは「暗号化キー」ではなく「完全性キー」です。
強力なキー付きMACを作成するためのよく知られた方法があり、これらのよく知られた方法の1つは「HMAC」と呼ばれます（簡単な説明についてはWikipediaを参照）。
SHA256ベースのHMACを使用する場合、オーバーヘッドは32バイト（256ビット）になります。
更新：コメントで述べたように、使用できるSHA256ハッシュ関数に代わるものがあります-HMACは任意のハッシュ関数で使用できますが、目的のために、暗号で保護されたハッシュ関数（SHA256など）を使用する必要があります。また、コメンテーターは、HMACタグを32バイトから16バイトなどの短い長さに切り詰めることができると述べています。これは本当です。トレードオフは、切り捨てによって攻撃者がタグを偽造しやすくなることですが、16バイトのタグと32バイトのタグの偽造における攻撃の難易度の違いは問題にならない場合があります。