我们能否加密必须使用任何私钥和服务器生成位解密的数据？
Can we encrypt data that must be decrypted with any private key plus a server generate bits?
我想出了一个制作安全数据的方案。假设我有一个任何人都可以下载的 public 加密文件。但是每当有人想要解密该数据时，他们都需要从服务器
获取密钥
使密钥无法共享。来自服务器的密钥将无法直接解密数据。但是数据必须用客户端的私钥解密，服务器不知道那些客户端的私钥
希望下图能解释清楚
可能吗？可以执行此操作的算法是什么？
the data must be decrypted with the client's private key after, without server knowing those client's privateKey
the original file can be decrypted only by a specific client, using their own private key,
有一种常用的密码系统称为 hybrid cryptosystem。
步骤是：
- 原始数据使用随机唯一密钥加密。
- 数据加密密钥由客户端的public密钥加密（服务器需要知道客户端的public密钥）。
- 客户端需要用自己的私钥解密文件加密密钥，解密文件
您可以使用任何非对称加密算法。
使用 public 和 private 密钥对。 public 密钥用于加密只能用私钥解密的数据。这方面有很多资源，例如文章形式 InfoSec Institute.
有几种经过验证的良好非对称算法，例如 RSA、DSA、椭圆曲线密码术（以太坊区块链使用）。还有很多 Python 个库。
I have come up with a scenario to make a secure data. Suppose I have a public encrypted
file that anybody can download. But whenever anyone want to decrypt that data they need to get a key from server
To make the key cannot be shared. The key from server will not be able to decrypt the
data directly. But the data must be decrypted with the client's
private key after, without server knowing those client's privateKey
这样设置每次下载文件时，都会附加一个随机字符串。然后使用用户的 public 密钥加密文件，并使用由同一字符串生成的适当散列对称加密。例如 password-protected ZIP 文件中的 GPG 文件。
因此，Alice 下载 Financial_Report_201809_d8a1b2e6.pdf.zip，而 Bob 下载 Financial_Report_201809_ff2a91c3.pdf.zip。
如果他们想解密文件，他们需要将随机字符串发回服务器，服务器会提供外层ZIP 的密码。然后他们会得到一个只有他们的私钥才能解码的加密文件。
请注意，一旦他们解密了文件，就无法阻止他们将明文文件转发给其他人。另一方面，共享加密的 PDF 对他们没有任何帮助，因为他们还需要共享他们的私钥。
另请注意，由于他们需要在线才能获取外部密码，并且最后会留下一个明文文件，这在功能上（几乎）等同于正在下载的文件一旦建立了用户身份，就明文显示.
主要区别是：
- 加密文件（上例中的 PDF）可能根本没有被服务器加密。它可能是由用户提供的，然后用户对只有他可以读回文件感到满意（尽管其他人下载它没有什么意义）。
- 传输的文件非常安全传输。拥有对数据流的完全访问权限的攻击者将无法解码文件（但这只不过是通过使用用户的 public 密钥加密可以获得的 - 不需要额外的 ZIP 阶段）。
更新
你想对整个文件只加密一次（对所有用户），然后将同一个文件发送给爱丽丝和鲍勃，让他们要求解密时有两个不同的密钥。这里的问题是爱丽丝的密钥也适用于鲍勃的文件，因为它是同一个文件。除非您可以隐藏解密过程的一些细节（例如，使用您控制且无法调试且将始终连接到您的服务器的程序：具有 一直在输).
如果您想限制加密成本，您可以发送带有对称加密数据负载（始终相同）和非常短的非对称加密密钥的大文件有效负载（总是不同），但仍然您将容易受到捕获的解密密钥的攻击：
[ RSA(ALICE.PUB, "SQUEAMISH OSSIFRAGE" ][ RIJNDAEL("SQUEAMISH OSSIFRAGE", LARGE FILE) ]
在上面的场景中，某些程序必须读取加密 header 并解密 'Squeamish Ossifrage' 密码，然后继续解密（例如播放）额外的有效载荷，而密码不会被拦截。这意味着您需要自己提供程序。
这在功能上等同于连接到服务器并下载“是”或“否”问题的程序（适当加密、签名和保护）“我是爱丽丝的玩家。我可以解密并播放 'Never Wanna Give You Up.avi'?" ，除了 Alice 的播放器和服务器共享的秘密外，没有密码或 public 密钥已知或交换。
更新二
如果目标是节省加密资源，可以按照评论中的提示在客户端进行加密：
- 文件使用 purpose-generated 私钥加密一次。
- 私钥存储在二进制文件中（我们必须假设它是不可破解的）。
- 用户必须提供他的 public 密钥才能进行解密
- 程序可以验证存储库中的 public 密钥（或者，用户可以向服务器提供 public 密钥，服务器将生成并发送二进制文件以供下载）
- 程序然后运行解密和重新加密
- 用户留下一个用他的 public 密钥加密的文件，只有他一个人可以解密。
更新三
为了永远不暴露明文文件（即算法是否泄露无关紧要），您可以设计以下方案。请记住，我不是密码学家，可能会有各种各样的侧通道未被发现。
- 您准备将每个 16 位字映射到另一个 16 位字的转换 table。这是一种对称加密，即使您使用两个互易矩阵进行编码和解码。每个矩阵包含所有可能的 16 位字，这意味着 65536 个值，因此大小为 128 Kb。
- 您使用加密矩阵对文件加密一次。没有解密矩阵，文件无法使用
- 用户必须将他的 public 密钥发送给您。
- 您通过使用该密钥加密每个单词来准备一个变形矩阵，一个使用解密值作为索引。
因此，例如，假设明文文件的第一个单词是 A18B。在加密矩阵中，经过加扰后，第 A18B 个位置将包含 701C，因此，在第 701C 个位置，解密矩阵将包含 a18b。
用户有一个以 701c... 开头的文件，没有用。
用户向您发送他的 public 密钥，您对从 0000 到 ffff 的所有单词进行 运行 65536 次加密。然后您确定 a18b 的加密是 791c。您准备一个 re-encoding 矩阵，其中第 701c 个位置为 791c。
然后你将这个矩阵发送给用户，它有128K字节，其中第701cth位置是791c。
用户运行进行了变形，速度非常快，并留下了一个以 791c 开头的文件（因为 701c 变成了 791c - 我在示例中错误地选择了两个相似的值，即无意义）。这个值，一旦用他的私钥解密，将产生 a18b，这是“可读”值。
用户现在拥有一个由他的 public 密钥加密的文件。 a18b 值从未出现在任何地方。
剩下的就是用户使用他的私钥和 16 位的代码块大小来解密文件。 这个操作会被客户端运行并且相当慢，这就是为什么通常一个大的随机快速对称密钥是RSA-encoded，并用于对称的原因快速加密大文件，私钥解开对称密钥后可快速解密
用户无法将 128K 发送给任何人，因为没有私钥他们就没用了。
（这里的问题仍然是用户现在可以用他的私钥解密文件，并发送它，即使它是一个非常大的文件很笨重）。
我想出了一个制作安全数据的方案。假设我有一个任何人都可以下载的 public 加密文件。但是每当有人想要解密该数据时，他们都需要从服务器
获取密钥使密钥无法共享。来自服务器的密钥将无法直接解密数据。但是数据必须用客户端的私钥解密，服务器不知道那些客户端的私钥
希望下图能解释清楚
可能吗？可以执行此操作的算法是什么？
the data must be decrypted with the client's private key after, without server knowing those client's privateKey
the original file can be decrypted only by a specific client, using their own private key,
有一种常用的密码系统称为 hybrid cryptosystem。
步骤是：
- 原始数据使用随机唯一密钥加密。
- 数据加密密钥由客户端的public密钥加密（服务器需要知道客户端的public密钥）。
- 客户端需要用自己的私钥解密文件加密密钥，解密文件
您可以使用任何非对称加密算法。
使用public 和 private 密钥对。 public 密钥用于加密只能用私钥解密的数据。这方面有很多资源，例如文章形式 InfoSec Institute.
有几种经过验证的良好非对称算法，例如 RSA、DSA、椭圆曲线密码术（以太坊区块链使用）。还有很多 Python 个库。
I have come up with a scenario to make a secure data. Suppose I have a public encrypted file that anybody can download. But whenever anyone want to decrypt that data they need to get a key from server
To make the key cannot be shared. The key from server will not be able to decrypt the data directly. But the data must be decrypted with the client's private key after, without server knowing those client's privateKey
这样设置每次下载文件时，都会附加一个随机字符串。然后使用用户的 public 密钥加密文件，并使用由同一字符串生成的适当散列对称加密。例如 password-protected ZIP 文件中的 GPG 文件。
因此，Alice 下载 Financial_Report_201809_d8a1b2e6.pdf.zip，而 Bob 下载 Financial_Report_201809_ff2a91c3.pdf.zip。
如果他们想解密文件，他们需要将随机字符串发回服务器，服务器会提供外层ZIP 的密码。然后他们会得到一个只有他们的私钥才能解码的加密文件。
请注意，一旦他们解密了文件，就无法阻止他们将明文文件转发给其他人。另一方面，共享加密的 PDF 对他们没有任何帮助，因为他们还需要共享他们的私钥。
另请注意，由于他们需要在线才能获取外部密码，并且最后会留下一个明文文件，这在功能上（几乎）等同于正在下载的文件一旦建立了用户身份，就明文显示.
主要区别是：
- 加密文件（上例中的 PDF）可能根本没有被服务器加密。它可能是由用户提供的，然后用户对只有他可以读回文件感到满意（尽管其他人下载它没有什么意义）。
- 传输的文件非常安全传输。拥有对数据流的完全访问权限的攻击者将无法解码文件（但这只不过是通过使用用户的 public 密钥加密可以获得的 - 不需要额外的 ZIP 阶段）。
更新
你想对整个文件只加密一次（对所有用户），然后将同一个文件发送给爱丽丝和鲍勃，让他们要求解密时有两个不同的密钥。这里的问题是爱丽丝的密钥也适用于鲍勃的文件，因为它是同一个文件。除非您可以隐藏解密过程的一些细节（例如，使用您控制且无法调试且将始终连接到您的服务器的程序：具有 一直在输).
如果您想限制加密成本，您可以发送带有对称加密数据负载（始终相同）和非常短的非对称加密密钥的大文件有效负载（总是不同），但仍然您将容易受到捕获的解密密钥的攻击：
[ RSA(ALICE.PUB, "SQUEAMISH OSSIFRAGE" ][ RIJNDAEL("SQUEAMISH OSSIFRAGE", LARGE FILE) ]
在上面的场景中，某些程序必须读取加密 header 并解密 'Squeamish Ossifrage' 密码，然后继续解密（例如播放）额外的有效载荷，而密码不会被拦截。这意味着您需要自己提供程序。
这在功能上等同于连接到服务器并下载“是”或“否”问题的程序（适当加密、签名和保护）“我是爱丽丝的玩家。我可以解密并播放 'Never Wanna Give You Up.avi'?" ，除了 Alice 的播放器和服务器共享的秘密外，没有密码或 public 密钥已知或交换。
更新二
如果目标是节省加密资源，可以按照评论中的提示在客户端进行加密：
- 文件使用 purpose-generated 私钥加密一次。
- 私钥存储在二进制文件中（我们必须假设它是不可破解的）。
- 用户必须提供他的 public 密钥才能进行解密
- 程序可以验证存储库中的 public 密钥（或者，用户可以向服务器提供 public 密钥，服务器将生成并发送二进制文件以供下载）
- 程序然后运行解密和重新加密
- 用户留下一个用他的 public 密钥加密的文件，只有他一个人可以解密。
更新三
为了永远不暴露明文文件（即算法是否泄露无关紧要），您可以设计以下方案。请记住，我不是密码学家，可能会有各种各样的侧通道未被发现。
- 您准备将每个 16 位字映射到另一个 16 位字的转换 table。这是一种对称加密，即使您使用两个互易矩阵进行编码和解码。每个矩阵包含所有可能的 16 位字，这意味着 65536 个值，因此大小为 128 Kb。
- 您使用加密矩阵对文件加密一次。没有解密矩阵，文件无法使用
- 用户必须将他的 public 密钥发送给您。
- 您通过使用该密钥加密每个单词来准备一个变形矩阵，一个使用解密值作为索引。
因此，例如，假设明文文件的第一个单词是 A18B。在加密矩阵中，经过加扰后，第 A18B 个位置将包含 701C，因此，在第 701C 个位置，解密矩阵将包含 a18b。
用户有一个以 701c... 开头的文件，没有用。
用户向您发送他的 public 密钥，您对从 0000 到 ffff 的所有单词进行 运行 65536 次加密。然后您确定 a18b 的加密是 791c。您准备一个 re-encoding 矩阵，其中第 701c 个位置为 791c。
然后你将这个矩阵发送给用户，它有128K字节，其中第701cth位置是791c。
用户运行进行了变形，速度非常快，并留下了一个以 791c 开头的文件（因为 701c 变成了 791c - 我在示例中错误地选择了两个相似的值，即无意义）。这个值，一旦用他的私钥解密，将产生 a18b，这是“可读”值。
用户现在拥有一个由他的 public 密钥加密的文件。 a18b 值从未出现在任何地方。
剩下的就是用户使用他的私钥和 16 位的代码块大小来解密文件。 这个操作会被客户端运行并且相当慢，这就是为什么通常一个大的随机快速对称密钥是RSA-encoded，并用于对称的原因快速加密大文件，私钥解开对称密钥后可快速解密
用户无法将 128K 发送给任何人，因为没有私钥他们就没用了。
（这里的问题仍然是用户现在可以用他的私钥解密文件，并发送它，即使它是一个非常大的文件很笨重）。