不确定您的问题，这些值是如何加密的？它在RFC-2548 第 2.4.2 节中进行了描述。

我认为这是因为在你的问题中你说：

我有一个 freeradius 的示例，会话密钥在构造 RFC 2548 中所述的字符串之前从 16 个字节长转换为 32 个字节长。

所以您想知道如何从 16 字节密钥变为 RADIUS 属性中使用的 32 字节值？

基本上，您的 32 字节密钥是 16 字节密钥的 2 个连接的 MD5 哈希。因此，该值必须是 16 的倍数。您拥有 32 而不是 16 的原因是您将单字节值16（用于键长度）添加到使长度为 17 的键值上，从而将其推入第二个 16 字节窗口。剩余的 15 个字节应该用 0 填充。

因此，无论如何，您正在使用 RADIUS 共享密钥、来自原始 RADIUS 请求的 16 字节请求身份验证器和随机的 2 字节盐值来加密您现在的 17 字节密钥值。

随机盐值实际上可以是任何东西。正如您所指出的那样，freeradius 是从 TLS 函数派生出来的，但这仅适用于您真正通过 TLS 进行隧道传输的情况。你可以从空中拉出一些东西。

然后你将两个字节的盐值添加到你的 32 字节加密值上，生成一个 34 字节的值，你就完成了！

     Construct a plaintext version of the String field by concate-
     nating the Key-Length and Key sub-fields.  If necessary, pad
     the resulting string until its length (in octets) is an even
     multiple of 16.  It is recommended that zero octets (0x00) be
     used for padding.  Call this plaintext P.

     Call the shared secret S, the pseudo-random 128-bit Request
     Authenticator (from the corresponding Access-Request packet) R,
     and the contents of the Salt field A.  Break P into 16 octet
     chunks p(1), p(2)...p(i), where i = len(P)/16.  Call the
     ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C.
     Intermediate values b(1), b(2)...c(i) are required.  Encryption
     is performed in the following manner ('+' indicates
     concatenation):

  b(1) = MD5(S + R + A)    c(1) = p(1) xor b(1)   C = c(1)
  b(2) = MD5(S + c(1))     c(2) = p(2) xor b(2)   C = C + c(2)
              .                      .
              .                      .
              .                      .
  b(i) = MD5(S + c(i-1))   c(i) = p(i) xor b(i)   C = C + c(i)

  The   resulting   encrypted   String   field    will    contain
  c(1)+c(2)+...+c(i).