* The sign array is the whole APDU.
* For payload of less than 256 bytes (for RSA keys of less than 2k),
we fit Lc part in one byte (instead of 3 as in template for larger keys),
which means the "header" is only 5 bytes long. The Le value is adjusted
on line 298.
* On the sixth byte (line 299), there already start PKCS#1.5-padded
data . This byte needs to be zero from 
* The line 300 marks where the intentional error is -- we are trying
to create bad PKCS#1.5 padding -- we overwrite it with 0xff padding later.
* The memmove() line is moving the tail of padded data (where the actual data
is stored) by shrinking the padding in the middle.
* The padding (for simplicity, 0xff bytes are used) starts on the 7th
byte and spans before the next 0x00 byte.
* The memmove(), in theory, should copy data up to the end of the
original, 256 bytes payload, but it can move also the last byte which
specifies the Le (handled separately)v. This means, we were 3 bytes off.
* target (&sign) -- this is the place where the padding starts in
the new buffer
* length (key_bits/8 - 1) -- the length of payload is 128 bytes, but
we already wrote the first byte (line 299).
* the source was wrong (&sign[sign_len-key_bits/8]) -- we need to find
a place where to start copying data from to match the ends of payloads
in the buffer (128 B and 256 B).
* The lines 302 and 303 adjust the buffer lengths and appends 0x01
(Le) of APDU.
 https://tools.ietf.org/html/rfc2313#section-8.1Signed-off-by: Jakub Jelen <firstname.lastname@example.org>