| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA512 |
| 3 |
|
| 4 |
On 01/13/2015 05:58 AM, Andrew Savchenko wrote: |
| 5 |
> On Mon, 12 Jan 2015 19:44:46 +0100 Kristian Fiskerstrand wrote: |
| 6 |
>> On 01/12/2015 07:29 PM, Rich Freeman wrote: |
| 7 |
>>> On Mon, Jan 12, 2015 at 1:06 PM, Kristian Fiskerstrand |
| 8 |
>>> <k_f@g.o> wrote: |
| 9 |
>>>> |
| 10 |
>>>> One issue with DSA/ElGamal is the requirement for a random k |
| 11 |
>>>> value while signing/encrypting, |
| 12 |
>>> |
| 13 |
>>> Thanks - that was very informative. I guess the thing that |
| 14 |
>>> makes me more concerned about RSA is that Shor's algorithm |
| 15 |
>>> makes it quite possible that it will be defeated at some point |
| 16 |
>>> in the future, perhaps without public disclosure. |
| 17 |
>> |
| 18 |
>> Shor's would be effective against discrete logs (including ECC) |
| 19 |
>> as well, so wouldn't be applicable to this selection. For |
| 20 |
>> post-quantum asymmetric crypto we'd likely need e.g a lattice |
| 21 |
>> based primitive. |
| 22 |
> |
| 23 |
> Why not to use post-quantum signing together with a traditional |
| 24 |
> one? app-crypt/codecrypt is already in tree and provides an |
| 25 |
> GnuPG-like solution based on post-quantum cryptography. |
| 26 |
|
| 27 |
My opinion is that it would only increase the complexity of things, in |
| 28 |
particular requiring a double set of trust paths / WoT. |
| 29 |
|
| 30 |
When such a shift becomes a prudent move (my interpretation of that is |
| 31 |
that it is advocated by people far more knowledgeable about crypto |
| 32 |
than I am) a lattice-based primitive (McEliece as used by this tool is |
| 33 |
part of this class) is likely to be brought into OpenPGP as an |
| 34 |
encryption algorithm by form of extension to RFC4880 (or part of an |
| 35 |
updated V5 key format). |
| 36 |
|
| 37 |
> |
| 38 |
> It would be no harm to use this solution together with GnuPG, e.g. |
| 39 |
> have two detached signatures: a traditional RSA-4096 and a |
| 40 |
> post-quantum one. |
| 41 |
|
| 42 |
The harm would be overhead, both computationally and not the least |
| 43 |
operationally to establish valid trust paths. Keep in mind that if it |
| 44 |
is to be any use, several steps would need to be fulfilled including |
| 45 |
that operational security perimeters would need to match the |
| 46 |
requirements, so all devs would need lattice-based keys in additional |
| 47 |
to classical keys, and probably make adjustments to their overall life |
| 48 |
to match such a key requirement. |
| 49 |
|
| 50 |
|
| 51 |
- -- |
| 52 |
Kristian Fiskerstrand |
| 53 |
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net |
| 54 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
| 55 |
-----BEGIN PGP SIGNATURE----- |
| 56 |
|
| 57 |
iQIcBAEBCgAGBQJUtNt/AAoJEPw7F94F4Tag2HcP+wZTK1vLR1q0fYlGTAUi7I8G |
| 58 |
3cWMrSAAVXqpfzezb7x/PYUm99y0G6gE9lmfkKQNG9sX6u/LsJDd7x6t92w99nI/ |
| 59 |
aJzYZi6WX5LKX7o22mFsSp8CjzJJwoNpdngKySjiTnFkMcsRmBANZnktsvxjKTS3 |
| 60 |
bgusId9LsT1w/hcXmIxmBUaM7hudffrV53XYdJtnlFPCCx6iLM4vQcjKxCQ60v67 |
| 61 |
LU11PWNw3Z7/M2UFHkWULMPYfezAUclTqdcMLTWNlWHugF2GJ8CTyrCTErV+ABKA |
| 62 |
f3awAB2rga2+gIwHiBtqPcepw8e0iFfzG3/NmQh2Q3+q6FwAgUyQL5NUzZI9GBqX |
| 63 |
xcwFJ2Y1OtMKvlJapHntZSXrwcj8uZvGC1DG+Srf0b+LF5JZUslp1F/aNPwHgpq/ |
| 64 |
GxM32EXtCHCN9w1BMlqrQSr1RE9NVKdcy43XEYSMA8D865+YqkHBnjylPrz5o+Q3 |
| 65 |
+r4iumNTBeyts7m4wWCcBHaFQCJJGsuy/JLcWQVTmq2zX3Y17atQh5UX83dzphP+ |
| 66 |
L8t3A0DXKdpJrbt0TcaxaYOaMcSp6eP+Two9UBRH3lJQzjydO70s2+YzyO55buJJ |
| 67 |
pjMZ1OAX/VH5NpNPWQlLUPWuZO9FlOarjYbg91DZtIEXf1d1/rTQ8edM/tbtq75Q |
| 68 |
pUPjmePbp6rw3y2AI4WF |
| 69 |
=MLZo |
| 70 |
-----END PGP SIGNATURE----- |
Archives