Clarify usage of config.s2kIterationCountByte

[redongh]

• OpenPGP.js version: 5.5.0
• Affected platform (Browser):
  • Brave 1.43.89 (Chromium 105.0.5195.102)
  • Firefox 104.0.1 (64-bit)

loading the following content saved to a file test.html into one of the browsers listed above (others not tested)

<script src="openpgp.js"></script>                                                                                    
<h3>test s2kIterationCountByte 65011712</h3>
<script lang="JavaScript">                                                                                            
(async () => {                                                                                                        
  const { privateKey, publicKey, revocationCertificate } = await openpgp.generateKey({                                
    type: 'ecc',
    curve: 'curve25519',
    config: { s2kIterationCountByte: 65011712 },                                                                                                       
    userIDs: [{ name: '', email: 'test@foo.bar' }],                                
    passphrase: 'iloveyou',                                                                 
    format: 'armored'          
  });

    console.log(privateKey);   // '-----BEGIN PGP PRIVATE KEY BLOCK ... '
    console.log(publicKey);    // '-----BEGIN PGP PUBLIC KEY BLOCK ... '
    console.log(revocationCertificate);  // '-----BEGIN PGP PUBLIC KEY BLOCK ... '
})();
</script>

and copying the generated privkey from the browsers console and feeding it into either pgpdump or gpg --list-packets yields a (protect) count of 1024 (coded count 0) instead an expected value of 65011712.
If the value given is diminished by one to 65011711, the result actually after pgpduming the privkey reads 65011712 so i suppose there is a minor flaw in the calculation of the value for the coded count which could have quite some security implications (render attacks more feasible and efficient) if not double checked.

[larabr]

The value needs to be of byte format, namely between 0-255. See the spec for more info about the value c (octect 10).

Indeed, we might want to add validation on the config to avoid confusion/unexpected results (cc @twiss)

[twiss]

Yes, I agree, we could check the range here. I also think that, to be fair, setting the iteration count rather than the iteration count byte would be a bit more intuitive, but would have some overhead which may or may not be worth it. But we could keep that in mind when designing the parameters for Argon2 (#1442), for example.