This delays opening (and locking) the keyring until all input has been
processed, and all possible errors that would make a chance that the
keyring doesn't have to be opened have been checked for.
Whole purpose was to enable codecrypt to be chained with pipes in UNIX-y way,
like this primitive certificate creation:
(echo "At `date` I certify this is The Key:" ; ccr -pa -F "the key") | ccr -s
...that provide around 1 million signatures per key. That seems more
than sufficient for human usage.
Note that generating the key takes 16 times longer than for already
present algorithms (that have H=16). On my computer, it is around 4
minutes for fmtseq128N20 and 16 minutes for fmtseq256N20.
Okay, this thing got public so it's time to make the RC4 rugged. Not
that I'd know about something that would break current implementation,
but it's nice to at least do the recommended discard correctly.
We'll probably be adding better symmetric ciphers anyway.
Note that this is an incompatible change (again). FMTSeq private keys
will need to be replaced. Existing signature validity doesn't change.
Encrypted messages will not be possible to decrypt.
codecrypt is usually invoked only with one prepare() and decrypt(), so
this basically saves several megs of memory and cuts needed computation
time in half.
to avoid possible known plaintext attacks on the symmetric cipher when
beginning of the ciphertext is known (which is a common situation, e.g.
when sign+encrypting)
It's quite rational to have such algorithm. 256-bit security is usually
an overkill, and this has two times smaller signatures (around 9.5kB) is
_so_ much faster. Use it.
Mirek Kratochvil