-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I want to mention that I want to keep a secret key in format OpenPGP not
a plain text.
In this context, the "multi-precision integers comprising the secret
key data" are the plaintext.
1) What value should I fill in IV?
In the secret key context, the IV should be filled with random bits.
That IV is included in the unencrypted section of the secret key packet.
For message packets, the IV is initially zero, but the first material
to be encrypted is random, which has similar effect.
2) Are those BS+2 octets just for plain text or even for secret key
material?
The "BS+2" scheme is only used in the Symmetrically Encrypted Data
("message") packets.
Secret key material is encrypted in a pure CFB mode; see below.
3. FRE is xored with the first BS octets of random data prefixed to
the plaintext to produce C[1] through C[BS], the first BS octets
of ciphertext.
3) Do the C[i] octets represent the final form for OpenPGP format?
Yes.
4) Let's assume that I encrypt the algorithm-specific portion with IDEA.
What it happens with the last block of data if the length of the
algorithm-specific portion is not multiple of 8 (64 bit)? (and, of
course, the last block it will be less than BS - in this case 8 octets)
CFB mode can use any "block size". The underlying cipher is always
applied to the "feedback register", which is a whole block, even if
the CFB input is smaller. If the CFB input is N bytes, only the first
N bytes of the encrypted feedback register are used; they are XORed
with the CFB input to form the CFB output. The CFB output is then
shifted into the feedback register.
The "block size" under CFB can even change from one input to the
next. To decrypt, you also need to know how the data was blocked.
RFC2440 uses the phrase "resync" to describe where blocks smaller
than the underlying cipher are processed. For example, at the
front of a message packet, a full block of random material is
processed, following by an 2-byte block of repeated material --
those two bytes are *not* combined with subsequent plaintext to
form a "full block", but are processed by themselves.
Also, version 3 secret keys are processed one MPI at a time
(including only the data, not the length), so the last bytes
of each MPI may be a short block.
Here is some Java-like pseudo-code for CFB that isn't tied to
the OpenPGP behavior.
Cipher engine; // underlying cipher, used in "ECB" mode
byte [] FR; // feedback register, block-sized; initialized with IV
void cfb_encrypt(byte [] src, byte [] dest, int length) {
// assumes length <= ECB block size; if not, reject or break up the input
// encrypt the FR, and XOR first "length" bytes with src into dest
byte [] FRE = engine.encrypt(FR);
for (int i = 0; i < length; i++)
dest[i] = src[i] ^ FRE[i];
// shift "length" bytes of result into FR
int j = 0;
for (int i = length; i < FR.length; i++) FR[j++] = FR[i];
for (int i = 0; j < FR.length; i++) FR[j++] = dest[i];
}
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBPG048VMkvpTT8vCGEQLuywCgmiCqp2qjFiKH0fSqqFnhz7Z6LScAn21L
OkR7fcgruGz8T/RzfX3jv+zm
=PnMc
-----END PGP SIGNATURE-----