通过套接字发送公钥的安全方式 [英] Safe way to sending a public key over a socket

问题描述

通过套接字发送RSA :: PublicKey给另一个用户的安全方法是什么？我想将密钥导出为ByteQueue，并将字节数组发送给用户，他可以再次构造公钥。

What is a safe way to send a RSA::PublicKey to another user over a socket? I was thinking to export the key into a ByteQueue and send the byte array to the user where he can construct the public key again.

或者这个泄漏信息可以滥用？

Or does this leak information that can be misuse?

//Generate keys
AutoSeededRandomPool rng;

InvertibleRSAFunction params;
params.GenerateRandomWithKeySize(rng, 3072);

//Create
RSA::PublicKey publicKey(params);

//Save
ByteQueue queue;
publicKey.Save(queue);

byte publicKeyBuffer[1000];
size_t size = queue.Get((byte*)&publicKeyBuffer, sizeof(publicKeyBuffer));

//Load
RSA::PublicKey loadkey;
ByteQueue queue2;
queue2.Put2((byte *)&publicKeyBuffer, size, 0, true);

loadkey.Load(queue2);

推荐答案

通过套接字发送RSA :: PublicKey给另一个用户的方式？

What is a safe way to send a RSA::PublicKey to another user over a socket?

是的，如果没有隐私，您可以发送纯文本关心。

Yes, you can send it plain text if privacy is not a concern. The person receiving it will need to authenticate the public key, meaning they will need to ensure its your genuine key, and not an imposter's key.

验证公钥是否需要验证公钥，这意味着他们需要确保其是您的真实密钥，而不是冒名顶替者的密钥。密钥分发问题，以及它在密码学中的一个棘手的问题。如果密钥分发问题可以解决，那么很多隐私问题就会消失。

Authenticating the public key is the key distribution problem, and its a wicked hard problem in cryptography. If the key distribution problem could be solved, then a lot of privacy issues go away.

尝试解决密钥分发问题的方法有两种：信任根信任网。信任根用于具有公共CA和私有CA的PKI;而信任网由PGP和朋友使用。

There are two ways to attempt to solve the key distribution problem: root of trust and web of trust. Root of trust is used in PKI with public and private CAs; while web of trust is used by PGP and friends.

密钥分发在PKI和公共CA的互联网上具有不同程度的成功度，被解决。例如，参见RFC 5280， Internet X.509公钥基础设施证书和证书吊销列表（CRL）简介，关于它应该如何工作;并参阅Peter Gutmann的工程安全 （有时以惊人的方式）。

The key distribution is 'solved' with varying degrees of success on the Internet with PKI and Public CAs. See, for example, RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, on how its supposed to work; and see Peter Gutmann's Engineering Security on how it fails in practice (sometimes in spectacular fashion).

对于不使用信任根或PKI的对等应用程序，最新的趋势是到（1）使用短认证字符串（SAS） / a>与初始消息，以及（2）将所有后续会话与过去会话（基本上形成来自第一会话的链）相关联。在初始消息期间，接收器通过读回诸如公钥指纹（语音是一种很好的认证机制）的小摘要，使用语音从发送者验证公钥密钥。

For peer to peer applications that don't use 'root of trust' or PKI, the latest trend is to (1) uses a Short Authentication String (SAS) with the initial message, and (2) tie all subsequent sessions to past sessions (essentially forming a chain from the first session). During the initial message, the receiver verifies the public key key from the sender using voice by reading back a small digest like a public key thumbprint (voice is a great authentication mechanism).

如果对等应用程序不能使用SAS来验证公钥，那么您应该采用首先使用信任（Trust-On-First-Use，TOFU）策略并实践密钥连续性。 Gutmann在他的书工程安全。

If your peer to peer application cannot use a SAS to verify the public key, then you should employ a Trust-On-First-Use (TOFU) strategy and practice key continuity. Gutmann goes into security diversification strategies in great detail in his book Engineering Security.

将密钥导出为ByteQueue并发送字节数组

export the key into a ByteQueue and send the byte array

这只是一个表示层次的细节。你可以以任何你喜欢的方式编码，包括原始，十六进制，Base32或Base64。真正的威胁是确保您的同事收到您发送的公钥（如 ntoskrnl 指出）。

This is just a presentation level detail. You could encode it any way you like, including raw, hexadecimal, Base32, or Base64. The real threat is ensuring your peer received the public key you sent (as ntoskrnl pointed out).

另请注意，隐私可能会成为一个问题，例如在受压迫国家的异议人士。异议人士和压迫性制度不是唯一的用例，它可能是认证和认证（C& A）以及。

Also note that privacy can be a concern, like folks who are dissidents in an oppressed country. Dissidents and oppressive regimes aren't the only use case, and it can be a concern for certification and accreditation (C&A) as well.

我在美国联邦的审计失败，因为我泄漏了一个电子邮件地址。在这种情况下，电子邮件地址与密钥一起位于用户证书中。 （所有的证书都是通过授权签名将公钥绑定到身份）。

I once failed an audit in US Federal because I leaked an email address. In this case, the email address was in a user certificate along with the key. (All a certificate does is bind a public key to an identity via an "authority" signature over both).

这篇关于通过套接字发送公钥的安全方式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！