Kerberos krb5p 是如何加密的？
How Kerberos krb5p does encryption?
全部，
我正在尝试将 NAS 驱动器安装到 Linux VM。
我有对传输中的数据进行加密的要求，即我希望在以下情况下对数据进行加密
它从 Linux 写入 NAS dribe
根据上述 link krb5p 提供数据加密。
krb5p：Kerberos 身份验证、数据完整性和数据隐私，方法是在通过网络发送数据之前对其进行加密。数据加密需要额外
https://www.varonis.com/blog/kerberos-authentication-explained/
我了解 Kerberos 相互身份验证的工作原理，但是一旦授予服务访问权限（在我的例子中是 NAS 驱动器），传输到 NAS 的数据将如何加密。
有人可以提供有关“加密”如何与 krb5p 一起使用的其他详细信息或文档吗？
我找不到任何其他详细信息。
根据：
https://whyistheinternetbroken.wordpress.com/tag/krb5p/
使用 krb5p 时：
NFS 数据包将使用 Kerberos 配置中指定的 enctype 进行加密。
但是可以指定的可用加密类型是什么？
我附上了一张试图解释消息流的图 b/w Server-KDC-Client
Kerberos 允许客户端和 KDC、KDC 和服务以及客户端和服务之间的相互身份验证。这是通过双方之间的密钥协议实现的。
客户端和 KDC 证明知道共享密钥，KDC 和服务证明知道不同的共享密钥，因此客户端和服务可以生成另一个随机密钥并相互同意。
换句话说，当客户端向服务发送票证时，它包含一个密钥，双方可以在身份验证成功后使用该密钥来加密数据。在这种情况下，该密钥用于保护 NFS 流量。
选择的加密类型有点不确定。这取决于所有三方都同意一个，并且每个人都有机会改变它。在实践中，最终决定权在服务端。它应该是它认为客户端可以处理的最强算法。这通常表示 RC4、AES128 或 AES256。
Kerberos 只提供加密密钥，但它本身并不会神奇地执行加密——这必须由 NFS 客户端和 NFS 服务器自己完成。他们知道 krb5p 已协商，并会在需要时调用相应的 encryption/decryption 函数。 （更具体地说，它发生在构建 NFS 的 SunRPC 层中。）
当 Kerberos KDC 向您发出“nfs/yourserver.example.com”的票据时，该票据包含随机生成的会话密钥的两份副本：一份可由您解密，另一份副本可由该服务器解密。
KDC 将使用最佳 enctype 标记此会话密钥，该 enctype 在您的票证请求中指示的内容与服务器主体持有的 long-term 密钥之间是常见的。通常这将是 AES256-CTS，但如果服务密钥在很长时间内未更改，则可以是 RC4 (arcfour)。
例如，
- “nfs/yourserver.example.com”主体有 long-term 个 aes256-cts-sha1-96、aes128-cts-sha1-96、arcfour-hmac 密钥， des3-cbc.
- 您的客户端制作 AS_REQ 表示支持 aes256-cts-sha384、aes128-cts-sha256、aes256-cts-sha1-96、aes128-cts-sha1-96。
- KDC 选择 aes256-cts-sha1-96 作为会话密钥的最佳加密类型。
此指示存储在票据本身中。如果客户端使用 MIT Krb5 软件，您可以使用 kvno 手动请求服务票据（如果您还没有）然后 klist -e 查看为该票据设置的 enctypes – ” skey" 表示会话密钥要使用的加密类型。
因此，在从 KDC 收到票据后，作为 RPCSEC_GSS 身份验证过程的一部分，您将其发送到 NFS 服务器，现在您和服务器都拥有会话密钥的副本。 （只要服务票有效，相同的会话密钥就会一直使用——通常是 10 小时。）
possible enctypes的集合是：
aes256-cts-hmac-sha384-192、aes128-cts-hmac-sha256-128：新的，大多数实现尚不支持（而且大多数服务也不会有该类型的密钥）。aes256-cts-hmac-sha1-96、aes128-cts-hmac-sha1-96：得到所有 Kerberos 实现的广泛支持。camellia256-cts-cmac、camellia128-cts-cmac：AES 的不错替代品，但在实践中很少使用。arcfour-hmac (RC4)：已弃用，但仍偶尔使用。从 Linux 5.10.des3-cbc-sha1：已弃用，但仍在实施。des-cbc-md5、des-cbc-crc：完全过时了。希望你永远不会看到那些。
（不要相信网页上说 Linux NFS 客户端仅支持 DES – 已在 2010 年为 v2.6.35 修复，现在完全支持 AES。）
全部，
我正在尝试将 NAS 驱动器安装到 Linux VM。 我有对传输中的数据进行加密的要求，即我希望在以下情况下对数据进行加密 它从 Linux 写入 NAS dribe
根据上述 link krb5p 提供数据加密。 krb5p：Kerberos 身份验证、数据完整性和数据隐私，方法是在通过网络发送数据之前对其进行加密。数据加密需要额外
https://www.varonis.com/blog/kerberos-authentication-explained/ 我了解 Kerberos 相互身份验证的工作原理，但是一旦授予服务访问权限（在我的例子中是 NAS 驱动器），传输到 NAS 的数据将如何加密。 有人可以提供有关“加密”如何与 krb5p 一起使用的其他详细信息或文档吗？ 我找不到任何其他详细信息。
根据： https://whyistheinternetbroken.wordpress.com/tag/krb5p/ 使用 krb5p 时： NFS 数据包将使用 Kerberos 配置中指定的 enctype 进行加密。
但是可以指定的可用加密类型是什么？
我附上了一张试图解释消息流的图 b/w Server-KDC-Client
Kerberos 允许客户端和 KDC、KDC 和服务以及客户端和服务之间的相互身份验证。这是通过双方之间的密钥协议实现的。
客户端和 KDC 证明知道共享密钥，KDC 和服务证明知道不同的共享密钥，因此客户端和服务可以生成另一个随机密钥并相互同意。
换句话说，当客户端向服务发送票证时，它包含一个密钥，双方可以在身份验证成功后使用该密钥来加密数据。在这种情况下，该密钥用于保护 NFS 流量。
选择的加密类型有点不确定。这取决于所有三方都同意一个，并且每个人都有机会改变它。在实践中，最终决定权在服务端。它应该是它认为客户端可以处理的最强算法。这通常表示 RC4、AES128 或 AES256。
Kerberos 只提供加密密钥，但它本身并不会神奇地执行加密——这必须由 NFS 客户端和 NFS 服务器自己完成。他们知道 krb5p 已协商，并会在需要时调用相应的 encryption/decryption 函数。 （更具体地说，它发生在构建 NFS 的 SunRPC 层中。）
当 Kerberos KDC 向您发出“nfs/yourserver.example.com”的票据时，该票据包含随机生成的会话密钥的两份副本：一份可由您解密，另一份副本可由该服务器解密。
KDC 将使用最佳 enctype 标记此会话密钥，该 enctype 在您的票证请求中指示的内容与服务器主体持有的 long-term 密钥之间是常见的。通常这将是 AES256-CTS，但如果服务密钥在很长时间内未更改，则可以是 RC4 (arcfour)。
例如，
- “nfs/yourserver.example.com”主体有 long-term 个 aes256-cts-sha1-96、aes128-cts-sha1-96、arcfour-hmac 密钥， des3-cbc.
- 您的客户端制作 AS_REQ 表示支持 aes256-cts-sha384、aes128-cts-sha256、aes256-cts-sha1-96、aes128-cts-sha1-96。
- KDC 选择 aes256-cts-sha1-96 作为会话密钥的最佳加密类型。
此指示存储在票据本身中。如果客户端使用 MIT Krb5 软件，您可以使用 kvno 手动请求服务票据（如果您还没有）然后 klist -e 查看为该票据设置的 enctypes – ” skey" 表示会话密钥要使用的加密类型。
因此，在从 KDC 收到票据后，作为 RPCSEC_GSS 身份验证过程的一部分，您将其发送到 NFS 服务器，现在您和服务器都拥有会话密钥的副本。 （只要服务票有效，相同的会话密钥就会一直使用——通常是 10 小时。）
possible enctypes的集合是：
aes256-cts-hmac-sha384-192、aes128-cts-hmac-sha256-128：新的，大多数实现尚不支持（而且大多数服务也不会有该类型的密钥）。aes256-cts-hmac-sha1-96、aes128-cts-hmac-sha1-96：得到所有 Kerberos 实现的广泛支持。camellia256-cts-cmac、camellia128-cts-cmac：AES 的不错替代品，但在实践中很少使用。arcfour-hmac(RC4)：已弃用，但仍偶尔使用。从 Linux 5.10. 消失
des3-cbc-sha1：已弃用，但仍在实施。des-cbc-md5、des-cbc-crc：完全过时了。希望你永远不会看到那些。
（不要相信网页上说 Linux NFS 客户端仅支持 DES – 已在 2010 年为 v2.6.35 修复，现在完全支持 AES。）