すべてのTCP / UDPポートを使用したステガノグラフィ？
アイデアが浮かんだのですが、思いついたときはすでに発明されていたので….
ポートを介して送信されるデータの代わりに（または追加で）ポート番号を介してメッセージを送信する、すべてのTCP/UDP接続をスニッフィングする複数のパーティで構成される標準はありますか？洗練されたポートノッキングシステム？そのようなシステムは、実際の接続を隠そうとする試みを検出するのを難しくしますか？
ポートのスニッフィングは低速です。大量のパケットを送信し、タイムアウトを使用して、開いているポートと開いていないポートを確認する必要があります。また、サーバーで開いているポートのリストが2分ごとに変更されることは非常にまれです。異常な設定を意味する場合、ステガノグラフィは存在できません。目立たないように努めています。
ソースポートでデータを非表示にすることができます。 UDPパケットをターゲットサーバーに送信するときはいつでも、パケットはtarget port（よく知られている、たとえばDNS要求の場合は53）と/でタグ付けされます。送信元ポート。送信元ポートはクライアント上で一時的に開いており、応答が送信された場合に応答を受信することを目的としています（これも、DNSの通常の状況です）。通常の状態では、送信元ポートはクライアントによってランダムに選択されます。アプリケーションはそれを気にする必要はありません、それはカーネルによって割り当てられます）。しかし、アプリケーションcouldは送信元ポートを選択し（パケットを送信する前のbind()システムコールの問題です）、したがって情報を秘密裏に伝達しますサーバーへのマナー。
そうすれば、無実に見えるDNS要求を装って、秘密の情報をサーバーに送信できます。オペレーティングシステムによって実行される通常のランダムポート割り当てを模倣するには、ほぼ同じ範囲に制限する必要があります。そのため、たとえば、要求ごとに約12ビットの情報を送信できます。秘密の転送を検出できないようにするには、データを暗号化する必要があります（送信元ポートは「ランダムに見える」必要があり、暗号化されたデータほどランダムに見えるものはありません）。
これは一般的なプロパティです。サーバーによってランダムに選択されるはずの要素がデータプロトコルに含まれている場合は常に、秘密のデータチャネルに転覆する可能性があります。これは、受信者が気付かないうちに送信者が重要なデータを第三者に漏らす可能性があるため、通常はセキュリティの問題と見なされます。例として、ブロック暗号が使用されている場合の SSL 3. （セクション5.2.3.2）のレコードデータのパディングがあります。パディングバイトの値は、送信者が任意に選択できます。これは TLS 1. で修正され、パディングバイトの値が適用されます。
パディングデータベクトルの各uint8には、パディング長の値を入力する必要があります。
ポート番号を介してステガノグラフィを行うための標準を知りません。あなたがそれに来るとき、それはかなり役に立たないように見えます。また、本質的に、「ステガノグラフィ」は「標準」とうまく混ざりません。