In fact, I have more than one question. For a CTF challenge, I am currently reading up on LFSRs. The code the challenge provides as an example is a 5-bit LFSR, and it generates from its bit sequences a 32-byte key (8-bit to one byte and this 32 times). So the first and last bytes of the key are the same for this particular 5-bit case as after $2^5-1$ iterations, the whole sequence repeats. Also, if I understand the whole logic behind a LSFR right, I can produce $2^5-1$ unique keys only for the 5-bit version. (starting with one particular seed, e.g., $s=1$). Also, I can have $2^5$ different initial seeds. So, according to my tests, this will not produce an additional 31 unique 32-byte keys but only duplicate keys in a shifted sequence.
Questions:
a) are the above statements as written correct, or did I miss something?
b) if the above is correct, then I can get up to 255 unique keys if using, as a minimum, an 8-bit LFSR ($2^8-1$). Right?
c) I will always get a max of 255 unique keys even if I increase the bits of the LFSR as I can only have 255 unique bytes, and the byte sequence will repeat. Is that correct?
d) So it doesn't make sense to increase the bits beyond 8 bits, or is there another benefit for this particular case that I don't see?

Edit:
Clarifying what I meant with unique 32-byte key: when I generate multiple 32-byte keys from an LFSR, I save the generated keys in a list, and each key appears only once in that list. I thought that when running an n-bit LFSR, the maximum number of 'unique' keys would be 255, but that might not be true, and I'll need to recheck that. Maybe someone can clarify this.

Draft paper linked from efail.de.
TL;DR: the vulnerability is in some popular email client software, often combined with an extension simplifying the use of an OpenPGP (e.g. GnuPG) or S/MIME implementation within the said software; e.g. an extension bundled in popular distributions of GnuPG v2, thus common.
The issue is that un-validated deciphered ciphertext is made available to the email client, and it acts upon it (e.g. following HTML links to addresses that an adversary collects), yielding a decryption oracle capable of deciphering a past or current ciphertext, and exfiltrating the plaintext.
It is fine to disable decryption functionality in the email client. It should remain so until that software (and any extension  it relies on) is checked or improved to suppress (or at least not automatically act upon and preferably flag as suspect) any deciphered plaintext that did not explicitly pass the Modification Detection Code test for OpenPGP, or a similar check (to be defined) for S/MIME.
For OpenPGP, we can get back to the manual use of the bare OpenPGP tool (e.g. gpg), checking from stderr output that an MDC check explicitly passed, otherwise not acting based on what's received, be it programmatically or manually. I have no workaround suggestion for S/MIME.

From an official statement by the GnuPG and Gpg4Win teams:


This paper is misnamed.  It's not an attack on OpenPGP.  It's an attack on broken email clients that ignore GnuPG's warnings and do silly things after being warned.
2.  This attack targets buggy email clients.  Correct use of the MDC completely prevents this attack.  GnuPG has had MDC support since the summer of 2000.



Update: based on that comment and other answer, and subject to dust settling, in GnuPG v2 two things are questionable, even if done on purpose so as not to break compatibility:
- Returning a status code of 0 (and a mere warning) in the absence of MDC, at least by default.
- A quirk specific to the Twofish algorithm prevents MDC error catching.
