384-bit ChaCha20 / Salsa20

Question

标准的Salsa20核是一个具有16字节常数( 32字节密钥的\sigma)、8字节nonce、8字节计数器和32字节密钥的\{0,1\}^{384} \to \{0,1\}^{512}随机函数。哈希函数不对输入类型进行任何区分。这留下了48个字节，可以随机选择。如果它们都是随机选择的，并且是保密的，那么这是否增加了2^{384}的密钥空间，还是有什么原因使密码的内部状态限制在256位以内？我之所以这样问是因为Linux内核随机驱动器 (称为CRNG)使用ChaCha20来生成随机性。

密码状态是在Linux内核中使用以下函数初始化的：

static void crng_initialize(struct crng_state *crng)
{
    int             i;
    unsigned long   rv;

    memcpy(&crng->state[0], "expand 32-byte k", 16);
    if (crng == &primary_crng)
        _extract_entropy(&input_pool, &crng->state[4],
                         sizeof(__u32) * 12, 0);
    else
        _get_random_bytes(&crng->state[4], sizeof(__u32) * 12);
    for (i = 4; i < 16; i++) {
        if (!arch_get_random_seed_long(&rv) &&
            !arch_get_random_long(&rv))
                rv = random_get_entropy();
        crng->state[i] ^= rv;
    }
    crng->init_time = jiffies - CRNG_RESEED_INTERVAL - 1;
}

状态保持在(struct crng_state *)crng->state中，前16个字节具有常量\sigma，最后48个字节是使用_extract_entropy()随机生成的，该函数返回请求的熵量。这是否意味着CRNG输出有一个2^{384}键空间？

如果对ChaCha20的攻击至少需要密码的2^{256}调用，那么增加密钥大小不会增加安全性(即使256已经足够了)。换句话说，具有256位密钥的ChaCha20是256位安全的，但我不知道具有384-bit密钥的ChaCha20是否是384-bit安全的。没有比蛮力更快的384位密钥攻击吗？

我完全意识到，即使是一个好的256位密码也被认为是不可能与现代技术相分离的，并且没有实际的理由使用更大的密钥。然而，有时了解给定数量的伪随机数据中存在多少熵是有用的。

Answer 1

是的，您可以控制$32$字节键+$$8$字节当前+$$8$字节计数器，总计$384$-bit键，这是非常安全的。

您对此函数的唯一责任是确保$(\text{Key}，\text{Nonce})$ tuple不再重复。PRG将增加和包装计数器，因此这可能开始随机。你仍然可以增加现在。您可以(但可能不应该)增加键。

或者，您可以使用标准得多的IETF变体的chacha20，有一个96位的nonce和$32的$-位计数器，或者使用$192$位的随机非can和没有暴露计数器的Xchacha20变种。

编辑：How我们确定chacha20没有上限为256位安全性吗？

常量、键、现在和计数器都被同等对待，因此在计数器中更改$1$-$2$比特是安全的。常量的存在是为了权衡对函数的控制，使其远离对手。对手可以控制$8$字节当前和$8$字节计数器，而不是$32$字节键或$16$字节常量。16/ 64美元=1/4美元。如果对手能够控制常量，那么它们就有1/2美元的输入。一个完整的$384$-bit密钥只给对手& of；/#>值知识的公共常量(而且他们知道计数器增量)。$512美元的密钥意味着对手不知道输入。