それらに機密情報が含まれていて、Cookieで送信する以外に解決策がない場合（おそらくそうではありません）。 pub/privキーモデルはブラウザ内で簡単に機能せず、おそらくあなたがしようとしていることを達成しないでしょう。
実際には、Cookieに機密情報を含めないでください。変更したくない状態データが含まれているものには、サーバーだけが知っている秘密を使用して、HMACなどを使用して署名する必要があります。
Cookieを安全にすることで暗号化する必要があります（HTTPS経由でのみ送信されます）。サーバー側のRSA/AESや類似のブラウザー側のRSA/AESで手動でデータを暗号化する理由は本当にありません。試みた場合、実装、識別、および鍵交換プロトコルに未解決の脆弱性が残る可能性があります。
Cookieには、相手側のブラウザーが表示または改ざんした場合に気にしない情報のみを含める必要があります。トランスポート層セキュリティ（TLS）を使用して、ネットワーク盗聴者がCookieを閲覧したり、Cookieを改ざんしたりできないようにします。
ユーザーに関連付ける必要があるシークレットがある場合は、それらのシークレットをサーバー側に保存し、次のいずれかを使用してユーザーに関連付けます。
- 推測することが不可能になるのに十分な長さのランダムセッショントークン（128ビットなど）、
- [〜＃〜] hmac [〜＃〜] を介して生成されたセッショントークンは、ユーザーを識別するサーバー側シークレットを使用してログイン時にサーバー側で生成されます。このセッションは、シークレットを使用する必要があるたびにサーバー側でチェックされます。
HMAC(username+login_timestamp, key = server_side_secret)のようなもので、基本的にユーザー情報とサーバー側の秘密鍵の組み合わせをハッシュします。次に、シークレットをユーザー名に関連付け、シークレットを使用する前に、HMACが有効であることを確認して、セッショントークンが有効であることを確認します。そのため、ユーザー名を（他のユーザーに）変更したり、ログイン日を変更したり（自動ログアウトを回避したり）する攻撃者は、有効なサインインユーザーを装うことはできません。
ああクッキー。 Webサーバーからの美味しい情報を少し。このテクノロジーは長い間使用されており、試され、真実であり、正しく実装されていれば非常にうまく機能します。
今、私は正しく実装されていると言いますが、それには理由があります。クッキーには情報が含まれています。 秘密情報を秘密にすることは最優先事項です。その情報がもう秘密ではない場合、何か悪いことが起こる可能性があります。これにより、Cookieを暗号化する必要があるかどうかを判断する最も簡単な方法が得られます。
このCookieには機密情報が含まれていますか？
はい：暗号
いいえ：何でも
それでは、Cookieをどのように暗号化する必要がありますか？まあそれはクッキーのタイプに依存します：
セッション/サーバー側のみ：ユーザーに変更を許可しない（非公開、サーバーのみで実行）
プライベートユーザーデータ：対称的で安全な暗号化により、ユーザーは内部の情報を使用できます
その後は、正しいアルゴリズムを使用してデータを安全に暗号化していることを確認し、それらが改ざんされていないことを確認するのに十分なチェックとバランスを持っていることを確認することがすべてです（JWTと考えてください）