Another possible private key protection method

NIIBE Yutaka gniibe at fsij.org
Thu May 26 09:11:43 CEST 2016


Hello,

I'm currently considering another private key protection method
(other than openpgp-s2k3-sha1-aes-cbc, openpgp-s2k3-ocb-aes, etc.).

I'm not sure if it's good for GnuPG, but in the context of Gnuk, it's
worth a try.

While we use AES (or some cipher) to encrypt a private key, the speed
of decryption to get private key is not that important, in this use
case.  In fact, we intentionally slow down the speed of the
computation of passphrase to private key (by a s2k function).

Here is the idea:

* Encryption

Input: PRIVATE_KEY of KEYSIZE
       PASSPHRASE
       SALT
       EXTRA_DATA
Output: ENCRYPTED_PRIVATE_KEY of KEYSIZE
        AUTHCODE of AUTHSIZE

(1) Have a seeded CSRNG (Cryptographically Secure Pseudo Random Number
    Generator), say, which is composed with SHA-2.  We feed PASSPHRASE
    + SALT + EXTRA_DATA as seed.  Note that the generation of random
    bytes is deterministic.

(2) For some predefined number of rounds (which matches enough
    computation time to prevent attack), we let generate as many bytes
    of random byte from the CSPRNG.

(3) Then, get another random bytes for private key and authcode
    (KEYSIZE+AUTHSIZE) from CSPRNG: RANDOM_DATA_FOR_KEY and
    RANDOM_DATA_FOR_AUTHCODE.

(4) Compute encrypted private key and authcode:

    ENCRYPTED_PRIVATE_KEY = RANDOM_DATA_FOR_KEY ^  PRIVATE_KEY
    AUTHCODE = RANDOM_DATA_FOR_AUTHCODE


It's something like the one-time pad system and a variant of Vernam
cipher.


* Decryption

Input: ENCRYPTED_PRIVATE_KEY of KEYSIZE
       AUTHCODE of AUTHSIZE
       PASSPHRASE
       SALT
       EXTRA_DATA
Output: PRIVATE_KEY of KEYSIZE

(1) Have a same seeded CSRNG.  We feed PASSPHRASE + SALT + EXTRA_DATA
    as seed.  If PASSPHRASE + SALT + EXTRA_DATA is correct, the CSRNG
    should generate exactly same sequence of random bytes.

(2) For some predefined number of rounds used in encryption process,
    we let generate as many bytes of random byte from the CSPRNG.

(3) Then, get another random bytes for private key and authcode
    (KEYSIZE+AUTHSIZE) from CSPRNG: RANDOM_DATA_FOR_KEY and
    RANDOM_DATA_FOR_AUTHCODE.

(4) Compute the private key and check against authcode

    if RANDOM_DATA_FOR_AUTHCODE == AUTHCODE
       PRIVATE_KEY = RANDOM_DATA_FOR_KEY ^ ENCRYPTED_PRIVATE_KEY
    else
       failure


Benefit for Gnuk is that we won't need to have AES implementation.
-- 



More information about the Gnupg-devel mailing list