Generate PGP keys very very fast
Clash Royale CLAN TAG#URR8PPP
$begingroup$
Is there a way to generate thousands of PGP keys at a very very fast rate?
I am generating thousands of 3072-bit PGP keys looking like part of a personal research project. Obviously, this is a very slow, CPU intensive activity. I have turned off strong randomization with the --debug-quick-random, am generating them using --batch and maxed out all of my personal CPUs. But this is still not fast enough.
Is there a way to generate perhaps thousands of keys very rapidly? My goal is to get a 16-bit hash collision on the KeyID. I know this is entirely impractical for real security, this is mostly for research purposes. I have not reviewed the GnuPG code, but I am trying to avoid writing any code just yet.
Thanks!
pgp key-generation
edited Feb 22 at 7:26
kelalaka
8,44322351
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
$endgroup$
add a comment |
$begingroup$
Is there a way to generate thousands of PGP keys at a very very fast rate?
I am generating thousands of 3072-bit PGP keys looking like part of a personal research project. Obviously, this is a very slow, CPU intensive activity. I have turned off strong randomization with the --debug-quick-random, am generating them using --batch and maxed out all of my personal CPUs. But this is still not fast enough.
Is there a way to generate perhaps thousands of keys very rapidly? My goal is to get a 16-bit hash collision on the KeyID. I know this is entirely impractical for real security, this is mostly for research purposes. I have not reviewed the GnuPG code, but I am trying to avoid writing any code just yet.
Thanks!
pgp key-generation
edited Feb 22 at 7:26
kelalaka
8,44322351
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
$endgroup$
3
$begingroup$
Do you require to have RSA keys? ECC keys can be generated much faster, and they're supported in the more recent versions of GPG.
$endgroup$
– Ruben De Smet
Feb 22 at 11:29
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
Feb 23 at 2:22
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
Feb 23 at 10:06
add a comment |
$begingroup$
Is there a way to generate thousands of PGP keys at a very very fast rate?
I am generating thousands of 3072-bit PGP keys looking like part of a personal research project. Obviously, this is a very slow, CPU intensive activity. I have turned off strong randomization with the --debug-quick-random, am generating them using --batch and maxed out all of my personal CPUs. But this is still not fast enough.
Is there a way to generate perhaps thousands of keys very rapidly? My goal is to get a 16-bit hash collision on the KeyID. I know this is entirely impractical for real security, this is mostly for research purposes. I have not reviewed the GnuPG code, but I am trying to avoid writing any code just yet.
Thanks!
pgp key-generation
edited Feb 22 at 7:26
kelalaka
8,44322351
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
$endgroup$
Is there a way to generate thousands of PGP keys at a very very fast rate?
I am generating thousands of 3072-bit PGP keys looking like part of a personal research project. Obviously, this is a very slow, CPU intensive activity. I have turned off strong randomization with the --debug-quick-random, am generating them using --batch and maxed out all of my personal CPUs. But this is still not fast enough.
Is there a way to generate perhaps thousands of keys very rapidly? My goal is to get a 16-bit hash collision on the KeyID. I know this is entirely impractical for real security, this is mostly for research purposes. I have not reviewed the GnuPG code, but I am trying to avoid writing any code just yet.
Thanks!
pgp key-generation
pgp key-generation
edited Feb 22 at 7:26
kelalaka
8,44322351
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
edited Feb 22 at 7:26
kelalaka
8,44322351
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
edited Feb 22 at 7:26
kelalaka
8,44322351
edited Feb 22 at 7:26
kelalaka
8,44322351
edited Feb 22 at 7:26
kelalaka
8,44322351
8,44322351
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
asked Feb 22 at 6:30
Farhan YusufzaiFarhan Yusufzai
61
61
3
$begingroup$
Do you require to have RSA keys? ECC keys can be generated much faster, and they're supported in the more recent versions of GPG.
$endgroup$
– Ruben De Smet
Feb 22 at 11:29
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
Feb 23 at 2:22
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
Feb 23 at 10:06
add a comment |
3
$begingroup$
Do you require to have RSA keys? ECC keys can be generated much faster, and they're supported in the more recent versions of GPG.
$endgroup$
– Ruben De Smet
Feb 22 at 11:29
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
Feb 23 at 2:22
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
Feb 23 at 10:06
3
3
$begingroup$
Do you require to have RSA keys? ECC keys can be generated much faster, and they're supported in the more recent versions of GPG.
$endgroup$
– Ruben De Smet
Feb 22 at 11:29
$begingroup$
Do you require to have RSA keys? ECC keys can be generated much faster, and they're supported in the more recent versions of GPG.
$endgroup$
– Ruben De Smet
Feb 22 at 11:29
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
Feb 23 at 2:22
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
Feb 23 at 2:22
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
Feb 23 at 10:06
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
Feb 23 at 10:06
add a comment |
2 Answers
2
active
oldest
votes
$begingroup$
To generate keys faster than you are doing right now probably requires to add a faster source of random numbers to your system. You could look at the extensions available in your CPU and checking if they are enabled or not on your system.
If you are only interested in looking for collision on key ID, you'd probably proceed differently.
fingerprint = hash(public_key)
public_key = timestamp + public_key_data
Therefore:
fingerprint = hash(timestamp + public_key_data)
There's a script that manipulate only the timestamp looking for a collision.
https://github.com/micahflee/trollwot
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
$endgroup$
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
Feb 22 at 8:41
3
$begingroup$
RSA key generation is slow. When the input is an ordinary PRNG (as is the case withgpg --debug-print-random, as opposed to using Linux's/dev/random), the RNG is not the limiting factor, it's the (pseudo-)primality tests.
$endgroup$
– Gilles
Feb 22 at 13:40
add a comment |
$begingroup$
Yes.
As rightly pointed in the first answer, we can make keys with identical public-key parameters but a different timestamp, which makes computing a fingerprint very fast. That seems by far the fastest/best to create collisions.
We create $kge2$ keys (say 16), compute fingerprints with varying timestamps, find a collision, and check that they are not with the same key (which as probability $1/k$). We can use the techniques in Paul C. van Oorschot and Michael J. Wiener, Parallel Collision Search with Cryptanalytic Applications, in Journal of Cryptology, 1999 to make that search with only little memory, and several independent devices (or independent data streams in SIMD/GPU computing).
In retrospect, PGP/GPG key fingerprint should have used a purposely slow hash rather than plain SHA-1. At least, something like PBKDF2; nowadays we'd use Argon2(id?), or Balloon Hashing.
I previously came up with speedup techniques, which are not useful for the task at hand. They RIP there.
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
$endgroup$
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
Feb 22 at 9:36
$begingroup$
It's not clear to me that there would be more value in using argon2 or whatever than in simply ditching the notion of short key ids in favour of consistently using full key fingerprints.
$endgroup$
– Squeamish Ossifrage
Feb 23 at 16:35
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
Feb 23 at 18:11
$begingroup$
@fgrieu It's not clear to me that collision attacks on PGP key fingerprints are relevant as PGP is more or less intended to be used by humans!
$endgroup$
– Squeamish Ossifrage
Feb 23 at 18:50
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
Feb 23 at 19:01
|
show 1 more comment
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
);
);
, "mathjax-editing");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f67529%2fgenerate-pgp-keys-very-very-fast%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
To generate keys faster than you are doing right now probably requires to add a faster source of random numbers to your system. You could look at the extensions available in your CPU and checking if they are enabled or not on your system.
If you are only interested in looking for collision on key ID, you'd probably proceed differently.
fingerprint = hash(public_key)
public_key = timestamp + public_key_data
Therefore:
fingerprint = hash(timestamp + public_key_data)
There's a script that manipulate only the timestamp looking for a collision.
https://github.com/micahflee/trollwot
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
$endgroup$
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
Feb 22 at 8:41
3
$begingroup$
RSA key generation is slow. When the input is an ordinary PRNG (as is the case withgpg --debug-print-random, as opposed to using Linux's/dev/random), the RNG is not the limiting factor, it's the (pseudo-)primality tests.
$endgroup$
– Gilles
Feb 22 at 13:40
add a comment |
$begingroup$
To generate keys faster than you are doing right now probably requires to add a faster source of random numbers to your system. You could look at the extensions available in your CPU and checking if they are enabled or not on your system.
If you are only interested in looking for collision on key ID, you'd probably proceed differently.
fingerprint = hash(public_key)
public_key = timestamp + public_key_data
Therefore:
fingerprint = hash(timestamp + public_key_data)
There's a script that manipulate only the timestamp looking for a collision.
https://github.com/micahflee/trollwot
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
$endgroup$
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
Feb 22 at 8:41
3
$begingroup$
RSA key generation is slow. When the input is an ordinary PRNG (as is the case withgpg --debug-print-random, as opposed to using Linux's/dev/random), the RNG is not the limiting factor, it's the (pseudo-)primality tests.
$endgroup$
– Gilles
Feb 22 at 13:40
add a comment |
$begingroup$
To generate keys faster than you are doing right now probably requires to add a faster source of random numbers to your system. You could look at the extensions available in your CPU and checking if they are enabled or not on your system.
If you are only interested in looking for collision on key ID, you'd probably proceed differently.
fingerprint = hash(public_key)
public_key = timestamp + public_key_data
Therefore:
fingerprint = hash(timestamp + public_key_data)
There's a script that manipulate only the timestamp looking for a collision.
https://github.com/micahflee/trollwot
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
$endgroup$
To generate keys faster than you are doing right now probably requires to add a faster source of random numbers to your system. You could look at the extensions available in your CPU and checking if they are enabled or not on your system.
If you are only interested in looking for collision on key ID, you'd probably proceed differently.
fingerprint = hash(public_key)
public_key = timestamp + public_key_data
Therefore:
fingerprint = hash(timestamp + public_key_data)
There's a script that manipulate only the timestamp looking for a collision.
https://github.com/micahflee/trollwot
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
edited Feb 22 at 12:55
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
answered Feb 22 at 8:17
ddddavideeddddavidee
2,70211429
2,70211429
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
Feb 22 at 8:41
3
$begingroup$
RSA key generation is slow. When the input is an ordinary PRNG (as is the case withgpg --debug-print-random, as opposed to using Linux's/dev/random), the RNG is not the limiting factor, it's the (pseudo-)primality tests.
$endgroup$
– Gilles
Feb 22 at 13:40
add a comment |
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
Feb 22 at 8:41
3
$begingroup$
RSA key generation is slow. When the input is an ordinary PRNG (as is the case withgpg --debug-print-random, as opposed to using Linux's/dev/random), the RNG is not the limiting factor, it's the (pseudo-)primality tests.
$endgroup$
– Gilles
Feb 22 at 13:40
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
Feb 22 at 8:41
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
Feb 22 at 8:41
3
3
$begingroup$
RSA key generation is slow. When the input is an ordinary PRNG (as is the case with
gpg --debug-print-random, as opposed to using Linux's /dev/random), the RNG is not the limiting factor, it's the (pseudo-)primality tests.$endgroup$
– Gilles
Feb 22 at 13:40
$begingroup$
RSA key generation is slow. When the input is an ordinary PRNG (as is the case with
gpg --debug-print-random, as opposed to using Linux's /dev/random), the RNG is not the limiting factor, it's the (pseudo-)primality tests.$endgroup$
– Gilles
Feb 22 at 13:40
add a comment |
$begingroup$
Yes.
As rightly pointed in the first answer, we can make keys with identical public-key parameters but a different timestamp, which makes computing a fingerprint very fast. That seems by far the fastest/best to create collisions.
We create $kge2$ keys (say 16), compute fingerprints with varying timestamps, find a collision, and check that they are not with the same key (which as probability $1/k$). We can use the techniques in Paul C. van Oorschot and Michael J. Wiener, Parallel Collision Search with Cryptanalytic Applications, in Journal of Cryptology, 1999 to make that search with only little memory, and several independent devices (or independent data streams in SIMD/GPU computing).
In retrospect, PGP/GPG key fingerprint should have used a purposely slow hash rather than plain SHA-1. At least, something like PBKDF2; nowadays we'd use Argon2(id?), or Balloon Hashing.
I previously came up with speedup techniques, which are not useful for the task at hand. They RIP there.
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
$endgroup$
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
Feb 22 at 9:36
$begingroup$
It's not clear to me that there would be more value in using argon2 or whatever than in simply ditching the notion of short key ids in favour of consistently using full key fingerprints.
$endgroup$
– Squeamish Ossifrage
Feb 23 at 16:35
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
Feb 23 at 18:11
$begingroup$
@fgrieu It's not clear to me that collision attacks on PGP key fingerprints are relevant as PGP is more or less intended to be used by humans!
$endgroup$
– Squeamish Ossifrage
Feb 23 at 18:50
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
Feb 23 at 19:01
|
show 1 more comment
$begingroup$
Yes.
As rightly pointed in the first answer, we can make keys with identical public-key parameters but a different timestamp, which makes computing a fingerprint very fast. That seems by far the fastest/best to create collisions.
We create $kge2$ keys (say 16), compute fingerprints with varying timestamps, find a collision, and check that they are not with the same key (which as probability $1/k$). We can use the techniques in Paul C. van Oorschot and Michael J. Wiener, Parallel Collision Search with Cryptanalytic Applications, in Journal of Cryptology, 1999 to make that search with only little memory, and several independent devices (or independent data streams in SIMD/GPU computing).
In retrospect, PGP/GPG key fingerprint should have used a purposely slow hash rather than plain SHA-1. At least, something like PBKDF2; nowadays we'd use Argon2(id?), or Balloon Hashing.
I previously came up with speedup techniques, which are not useful for the task at hand. They RIP there.
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
$endgroup$
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
Feb 22 at 9:36
$begingroup$
It's not clear to me that there would be more value in using argon2 or whatever than in simply ditching the notion of short key ids in favour of consistently using full key fingerprints.
$endgroup$
– Squeamish Ossifrage
Feb 23 at 16:35
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
Feb 23 at 18:11
$begingroup$
@fgrieu It's not clear to me that collision attacks on PGP key fingerprints are relevant as PGP is more or less intended to be used by humans!
$endgroup$
– Squeamish Ossifrage
Feb 23 at 18:50
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
Feb 23 at 19:01
|
show 1 more comment
$begingroup$
Yes.
As rightly pointed in the first answer, we can make keys with identical public-key parameters but a different timestamp, which makes computing a fingerprint very fast. That seems by far the fastest/best to create collisions.
We create $kge2$ keys (say 16), compute fingerprints with varying timestamps, find a collision, and check that they are not with the same key (which as probability $1/k$). We can use the techniques in Paul C. van Oorschot and Michael J. Wiener, Parallel Collision Search with Cryptanalytic Applications, in Journal of Cryptology, 1999 to make that search with only little memory, and several independent devices (or independent data streams in SIMD/GPU computing).
In retrospect, PGP/GPG key fingerprint should have used a purposely slow hash rather than plain SHA-1. At least, something like PBKDF2; nowadays we'd use Argon2(id?), or Balloon Hashing.
I previously came up with speedup techniques, which are not useful for the task at hand. They RIP there.
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
$endgroup$
Yes.
As rightly pointed in the first answer, we can make keys with identical public-key parameters but a different timestamp, which makes computing a fingerprint very fast. That seems by far the fastest/best to create collisions.
We create $kge2$ keys (say 16), compute fingerprints with varying timestamps, find a collision, and check that they are not with the same key (which as probability $1/k$). We can use the techniques in Paul C. van Oorschot and Michael J. Wiener, Parallel Collision Search with Cryptanalytic Applications, in Journal of Cryptology, 1999 to make that search with only little memory, and several independent devices (or independent data streams in SIMD/GPU computing).
In retrospect, PGP/GPG key fingerprint should have used a purposely slow hash rather than plain SHA-1. At least, something like PBKDF2; nowadays we'd use Argon2(id?), or Balloon Hashing.
I previously came up with speedup techniques, which are not useful for the task at hand. They RIP there.
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
edited Feb 22 at 12:33
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
answered Feb 22 at 8:29
fgrieufgrieu
81.6k7176348
81.6k7176348
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
Feb 22 at 9:36
$begingroup$
It's not clear to me that there would be more value in using argon2 or whatever than in simply ditching the notion of short key ids in favour of consistently using full key fingerprints.
$endgroup$
– Squeamish Ossifrage
Feb 23 at 16:35
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
Feb 23 at 18:11
$begingroup$
@fgrieu It's not clear to me that collision attacks on PGP key fingerprints are relevant as PGP is more or less intended to be used by humans!
$endgroup$
– Squeamish Ossifrage
Feb 23 at 18:50
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
Feb 23 at 19:01
|
show 1 more comment
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
Feb 22 at 9:36
$begingroup$
It's not clear to me that there would be more value in using argon2 or whatever than in simply ditching the notion of short key ids in favour of consistently using full key fingerprints.
$endgroup$
– Squeamish Ossifrage
Feb 23 at 16:35
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
Feb 23 at 18:11
$begingroup$
@fgrieu It's not clear to me that collision attacks on PGP key fingerprints are relevant as PGP is more or less intended to be used by humans!
$endgroup$
– Squeamish Ossifrage
Feb 23 at 18:50
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
Feb 23 at 19:01
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
Feb 22 at 9:36
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
Feb 22 at 9:36
$begingroup$
It's not clear to me that there would be more value in using argon2 or whatever than in simply ditching the notion of short key ids in favour of consistently using full key fingerprints.
$endgroup$
– Squeamish Ossifrage
Feb 23 at 16:35
$begingroup$
It's not clear to me that there would be more value in using argon2 or whatever than in simply ditching the notion of short key ids in favour of consistently using full key fingerprints.
$endgroup$
– Squeamish Ossifrage
Feb 23 at 16:35
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
Feb 23 at 18:11
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
Feb 23 at 18:11
$begingroup$
@fgrieu It's not clear to me that collision attacks on PGP key fingerprints are relevant as PGP is more or less intended to be used by humans!
$endgroup$
– Squeamish Ossifrage
Feb 23 at 18:50
$begingroup$
@fgrieu It's not clear to me that collision attacks on PGP key fingerprints are relevant as PGP is more or less intended to be used by humans!
$endgroup$
– Squeamish Ossifrage
Feb 23 at 18:50
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
Feb 23 at 19:01
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
Feb 23 at 19:01
|
show 1 more comment
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f67529%2fgenerate-pgp-keys-very-very-fast%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
$begingroup$
Do you require to have RSA keys? ECC keys can be generated much faster, and they're supported in the more recent versions of GPG.
$endgroup$
– Ruben De Smet
Feb 22 at 11:29
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
Feb 23 at 2:22
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
Feb 23 at 10:06