What is “Fast Prime”? In this note, the manufacturer of a RSA key generation gizmo vulnerable to the new ROCA attack (see second section) explains that


  it is common practice to employ acceleration algorithms in order to generate key pairs, especially if time resources are sparse. (We) also utilizes such an acceleration algorithm in time-restricted cases, called “Fast Prime”. This algorithm is software-based..
  
  The foundations of “Fast Prime” date back to the year 2000. Its use started around ten years later after thorough reviews. As a sub-part of one cryptographic software library which is supplied to customers as a basis for their own development, this software function was certified by the BSI (Federal Office for Information Security) in Germany. No mathematical weaknesses were known, nor have been discovered during the certification processes.


What is “Fast Prime” and where was it suggested?

The following (likely) tells a property of primes generated by this method; but not how it really works, if that's a deliberate and/or following some article/method, if there was some goof at some point; which I ask.



The ROCA vulnerability/attack targets some RSA keys generated using “Fast Prime”. Details are in the paper: Matus Nemec, Marek Sys, Petr Svenda, Dusan Klinec, Vashek Matyas; The Return of Coppersmith’s Attack: Practical Factorization of Widely Used RSA Moduli published at CCS 2017 (in a slightly earlier version).

Paraphrasing that article: the factors making the attack possible (presumably, those generated by “Fast Prime” ) are of the form
$$p=k\;M+(65537^a\bmod M) \ \ \text{ where } M=P_n\#=\prod_{i=1}^n p_i$$
with $p_i$ is the $i^\text{th}$ prime.

It follows that any public modulus $N$ made from primes generated in this way is such that $N\equiv65537^a\pmod{P_n\#}$ for some integer $a$.

The integer $n$ is chosen according to the desired bit size of $p$ (which is always multiple of 16), by discrete steps, in a way such that $P_n\#$ is a large fraction of the size of $p$
$$\begin{array}{c|ccc}
\text{bits in }p &amp; n &amp; p_n &amp; \text{bits in }P_n\#\\
\hline
 256 \dots  480 &amp;  39 &amp;  167 &amp;  220 \\
 496 \dots  976 &amp;  71 &amp;  353 &amp;  475 \\
 992 \dots 1968 &amp; 126 &amp;  701 &amp;  971 \\
1984 \dots 2048 &amp; 225 &amp; 1427 &amp; 1963 \\
\end{array}$$

A former version of this question discussed the first published ROCA test for vulnerable keys. However that's obsolete: it turns out this test was intentionally simplified to limit disclosure about the vulnerability; the full test has even lower odds of false detection.
This is a tentative guess at answering my own question.

Perhaps the "Fast Prime" method alluded to in the question's citation is that of these two papers (the second polishing the first):


[JPV2000]: Marc Joye, Pascal Paillier, and Serge Vaudenay; Efficient generation of prime numbers, in proceedings of CHES 2000
[JP2006]: Marc Joye and Pascal Paillier; Fast Generation of Prime Numbers on Portable Devices: An Update, in proceedings of CHES 2006 (slides). 


Several things match:


The objective of the articles is clearly the one pursued by the technique used.
"Fast Prime" is two words from the title of [JP2006].
"date back to the year 2000" is matched by the publication of [JPV2000].
"use started around ten years later after thorough reviews" allows [JP2006] to get published and reviewed.
From what we know, the prime generator makes heavy use of an $M=P_n\#=\displaystyle\prod_{i=1}^n p_i$, essentially as [JPV2000] and [JP2006] do (their $\Pi$ is $M/2$).


However, the technique in [JP2006] is proven to generate almost random primes, and is not susceptible to the ROCA attack. Hence if my theory is right, there has been a serious implementation goof.

The fact that $65537^a$ occurs makes me wonder if the cause of the goof might be a deliberate attempt, gone horribly wrong, to make it faster to compute $e^{-1}\bmod p$ with $e=65537$; or perhaps just insure that it is defined.



Update: as noticed in comment, Daniel J. Bernstein and Tanja Lange's blog confirms an attempt at implementing [JP2006] gone wrong:


  A related algorithm "GenPrime" was published by Joye and Paillier in 2006. The Joye–Paillier generator, like Lehmer's generator, starts from a new random number $r$ coprime to $L$ and then multiplies repeatedly by a constant $g$ modulo $L$, obtaining $r$ times a power of $g$. This can produce any number modulo $L$, and produces only a slight bias in the resulting primes. The guess was that (company) was oversimplifying and generating merely a power of $g$; this produces far fewer numbers modulo $L$.
  
  The authors wrote back promptly, confirming that this guess was correct but not revealing more details.