This is an alternative to the approach taken in #11340

I gotta say that I have very little understanding for separating out the first factors, exponents and coefficient. P, Q, etc are really just historical artefacts, there's nothing special about them.

All in all, I like this approach muuuuuch better than #11340.

I gotta say that I have very little understanding for separating out the first factors, exponents and coefficient. P, Q, etc are really just historical artefacts, there's nothing special about them.

Multi-primes are a legacy item as far as I can tell.
To be honest I really don't think much of the multiple keys with the same name.
The normal general case should not be multi-primes.
Hence to me - it makes sense to leave them as separate fields.

All in all, I like this approach muuuuuch better than #11340.

Are you happy with this approach going forward - so I can apply it to other key types?

Multi-primes are a legacy item as far as I can tell.

Er, what? Not sure I understand... As far as I understand, multi-primes is an extension of the original RSA

Are you happy with this approach going forward - so I can apply it to other key types?

Generally yes. This is the route I was hoping for.

Er, what? Not sure I understand... As far as I understand, multi-primes is an extension of the original RSA

I dont see it ever becoming part of the fips standards.
The point is it is easier to understand the 1-1 mapping for the normal case (which is not multiprime)

Multi-primes are a legacy item as far as I can tell.

Multi-prime support was very recently added. I don't think we get to call it legacy yet.

Multi-prime support was very recently added. I don't think we get to call it legacy yet.

The paper was published in 2000 - so yeah they are pretty new - relatively speaking :)

https://tools.ietf.org/html/rfc8017 describes the parameters as
p, q, dp, dq, qinv and then additional parameters for the multi-primes.
I would prefer to keep it looking like the standard does.
There is not much gain in collapsing them and then having to assign them with weird indexes back to the internal format which matches the actual standards.
These arrays with the same key names are ugly - having them now all be the same size is a good thing.

The paper was published in 2000 - so yeah they are pretty new - relatively speaking :)

But the code was added to OpenSSL just over 2 years ago...

Ok I retract the word legacy :) - my reasons remain the same.

Closed and replaced by #11365.

I suspect that the main reason for keeping the original factors, exponents and coefficients is to not break backward compatibility on an ASN.1 level. You'll notice that between RFC 2437 and RFC 8017, the difference for the RSAPrivateKey structure, the difference is this:

: ; diff -u rsa1.txt rsa2.txt 
--- rsa-rfc2437.txt	2020-03-19 11:53:16.827269974 +0100
+++ rsa-rfc8017.txt	2020-03-19 11:52:58.567005639 +0100
@@ -7,5 +7,6 @@
     prime2            INTEGER,  -- q
     exponent1         INTEGER,  -- d mod (p-1)
     exponent2         INTEGER,  -- d mod (q-1)
-    coefficient       INTEGER   -- (inverse of q) mod p
+    coefficient       INTEGER,  -- (inverse of q) mod p
+    otherPrimeInfos   OtherPrimeInfos OPTIONAL
 }

I.e. to not break DER encoded 2-prime RSA keys, they had to place the added factors, exponents and coefficients separately, and make them optional.

However, if you look at the publications that presented multi-prime without ties to structures, such as https://www.researchgate.net/publication/324425605_Modified_Multi_Prime_RSA_Cryptosystem, you'll notice that apart from the Bob example with 3 primes (named p, q and r, because that's how math folks name incrementing amounts of the same thing), p and q don't really hold any special status. As a matter of fact, if you read on to the 5-prime example, you'll see that they have forgone the letters entirely, and just talk about a set of 5 primes.

I can go on, just to hammer in that last nail; If you look in RFC 8017, section 3.2, you'll notice this (emphasis mine):

2. The second representation consists of a quintuple (p, q, dP, dQ,
   qInv) and a (possibly empty) sequence of triplets (r_i, d_i,
   t_i), i = 3, ..., u, one for each prime not in the quintuple,
   where the components have the following meanings:

That the index starts with 3 is a sure indication, at least to me, that they do view p, q as part of the whole set of factors, exponents and coefficients, but had to do it like this because of ASN.1 backward compatibility demands.

The libcrypto <-> provider interface isn't designed to be driven by ASN.1 demands. So while we may still choose it, I personally don't see that as a good justification.

I DONT LIKE THE CRAPPY ARRAYS THAT ARE DIFFERENT SIZES.
It is not pretty using them at all.
For the normal case (which is not multiprime) P,Q, DP, DQ, QINV are more expressive.
As you are not willing to budge I guess I will undo the changes.
I dont agree with you.

I dont agree with you.

Which is fine. Most of all, we're looking at it from different point of view. You're stuck on differently sized array, I'm stuck on a set of factors between divided into two named slots and an array. Different uglies, basically.