I think using multi prime is about 7 to 9 times faster in decryption than regular RSA decryption (depending on implementation).
What I don't know is how much slower a key with r > 2 is when only using d is vs the standard case of using d where r = 2. I think looking at key generation that they are the same, but someone smarter than me needs to confirm that. As I recall the idea behind multi-prime was to speed up decryption to make RSA practical on mobile platforms of the day. (the alternative being EC) That is less of an issue now given speed improvements, though might now be an issue for IoT platforms (I suspect they are all using EC anyway). If using d is a significant enough slowdown that it can be a denial of service attack then perhaps the decrypter shouldn't be using RSA keys in the first place. If decryption using a multi prime private key only using d where r >2 is the same as or similar to decryption using d where r = 2 then I would go with Mike's wording, but add a security consideration around the performance issues with RSA decryption if people think that is required. John B. (PS this math stuff makes my head hurt so I may be completely wrong) > On Nov 17, 2014, at 11:11 AM, ⌘ Matt Miller <[email protected]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Technically, only the private exponent and the modulus are necessary > for the private operations. However, the performance can be so bad > that it be a Denial of Service attack. Better to reject, in my opinion. > > > - -- > - - m&m > > Matt Miller < [email protected] > > Cisco Systems, Inc. > > On 11/10/14, 10:08 PM, Mike Jones wrote: >> Clarification question: Would the private key operate correctly, >> if possibly inefficiently, in the multi-prime case if all the >> private key parameters other than “d” were ignored? I ask, because >> if this is the case, your wording could be modified to the less >> severe text: >> >> >> >> If the consumer of a JWK does not support multi-prime RSA moduli >> and it encounters a private key that includes the "oth" parameter, >> then it MUST either reject the key or ignore all the private key >> parameters other than “d”. >> >> >> >> -- Mike >> >> >> >> *From:*jose [mailto:[email protected]] *On Behalf Of *Richard >> Barnes *Sent:* Monday, November 10, 2014 7:02 PM *To:* >> [email protected] *Subject:* [jose] Clean interop with "oth" >> >> >> >> It seems clear that there are no implementations today that support >> the "oth" element, i.e., that support RSA with a modulus with >> multiple factors. At least some of them simply ignore the "oth" >> element, which unfortunately leads to incorrect operation. I would >> propose something of the following form in JWA: >> >> """ >> >> If the consumer of a JWK does not support multi-prime RSA moduli >> and it encounters a private key that includes the "oth" parameter, >> then it MUST reject the key. >> >> """ >> >> >> >> _______________________________________________ jose mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/jose >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > > iQEcBAEBCgAGBQJUah5OAAoJEDWi+S0W7cO13kQIALa+juv24iNuIdr/PdHlRjee > 0nGeSq/xIk5WZsV+tYWk8mMUSWqxoh3FTUd2flpj4vjQ7iZvraQmJwV+4jcRsZOY > UM3JyL5cBvAnOtNXtwga5N7Y+2G1vWvjJGURo+9lNI+Kn3Ut7mAG+u6q8kob72Wv > g0U1lJmjtkslDeFXnNJQSI5AliKPc1Gvo/sbzR0QH5oZeIdwsoqBdYwFSU0a4g7f > 1MEtgf0ASE2ShhNBDpgPnQg0OOrptARSkndvhirtyhoBgm473WWW0fr+pj0A6V7n > vsuzLNSFishXPNfIERfME+qacL0IYl6ZjVt2GumiMesi7epD/AMHucUHXGEN5X8= > =ijfD > -----END PGP SIGNATURE----- > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
