Generate PGP keys very very fast
$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 yesterday
kelalaka
8,03322350
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$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 yesterday
kelalaka
8,03322350
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$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
yesterday
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
22 hours ago
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
14 hours ago
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 yesterday
kelalaka
8,03322350
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
$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 yesterday
kelalaka
8,03322350
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
kelalaka
8,03322350
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited yesterday
kelalaka
8,03322350
edited yesterday
kelalaka
8,03322350
edited yesterday
kelalaka
8,03322350
8,03322350
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
asked yesterday
Farhan YusufzaiFarhan Yusufzai
61
61
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Farhan Yusufzai is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
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
yesterday
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
22 hours ago
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
14 hours ago
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
yesterday
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
22 hours ago
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
14 hours ago
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
yesterday
$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
yesterday
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
22 hours ago
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
22 hours ago
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
14 hours ago
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
14 hours ago
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 yesterday
ddddavideeddddavidee
2,70411429
$endgroup$
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
yesterday
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
yesterday
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 yesterday
fgrieufgrieu
80.4k7171338
$endgroup$
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
yesterday
$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
8 hours ago
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
6 hours ago
$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
5 hours ago
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
5 hours ago
|
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
});
}
});
Farhan Yusufzai is a new contributor. Be nice, and check out our Code of Conduct.
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 yesterday
ddddavideeddddavidee
2,70411429
$endgroup$
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
yesterday
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
yesterday
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 yesterday
ddddavideeddddavidee
2,70411429
$endgroup$
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
yesterday
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
yesterday
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 yesterday
ddddavideeddddavidee
2,70411429
$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 yesterday
ddddavideeddddavidee
2,70411429
edited yesterday
answered yesterday
ddddavideeddddavidee
2,70411429
answered yesterday
ddddavideeddddavidee
2,70411429
answered yesterday
ddddavideeddddavidee
2,70411429
2,70411429
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
yesterday
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
yesterday
add a comment |
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
yesterday
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
yesterday
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
yesterday
$begingroup$
+1 for the idea of changing only the timestamp!
$endgroup$
– fgrieu
yesterday
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
yesterday
$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
yesterday
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 yesterday
fgrieufgrieu
80.4k7171338
$endgroup$
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
yesterday
$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
8 hours ago
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
6 hours ago
$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
5 hours ago
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
5 hours ago
|
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 yesterday
fgrieufgrieu
80.4k7171338
$endgroup$
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
yesterday
$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
8 hours ago
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
6 hours ago
$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
5 hours ago
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
5 hours ago
|
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 yesterday
fgrieufgrieu
80.4k7171338
$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 yesterday
fgrieufgrieu
80.4k7171338
edited yesterday
answered yesterday
fgrieufgrieu
80.4k7171338
answered yesterday
fgrieufgrieu
80.4k7171338
answered yesterday
fgrieufgrieu
80.4k7171338
80.4k7171338
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
yesterday
$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
8 hours ago
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
6 hours ago
$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
5 hours ago
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
5 hours ago
|
show 1 more comment
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
yesterday
$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
8 hours ago
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
6 hours ago
$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
5 hours ago
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
5 hours ago
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
yesterday
$begingroup$
I liked the "other speedup techniques". I'm glad they're still in the revision history.
$endgroup$
– ddddavidee
yesterday
$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
8 hours ago
$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
8 hours ago
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
6 hours ago
$begingroup$
@Squeamish Ossifrage: full key fingerprints are SHA-1 hashes. That's vulnerable to collision (not preimage, fortunately).
$endgroup$
– fgrieu
6 hours ago
$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
5 hours ago
$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
5 hours ago
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
5 hours ago
$begingroup$
@Squeamish Ossifrage Show two colliding keys to a human that is not a cryptographer and s/he wont trust fingerprints anymore.
$endgroup$
– fgrieu
5 hours ago
|
show 1 more comment
Farhan Yusufzai is a new contributor. Be nice, and check out our Code of Conduct.
Farhan Yusufzai is a new contributor. Be nice, and check out our Code of Conduct.
Farhan Yusufzai is a new contributor. Be nice, and check out our Code of Conduct.
Farhan Yusufzai is a new contributor. Be nice, and check out our Code of Conduct.
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
yesterday
$begingroup$
Do you need your own or could you use the (32-bit) ones already found?
$endgroup$
– dave_thompson_085
22 hours ago
$begingroup$
I believe the pqRSA paper gives some information on optimizing batch prime number generation.
$endgroup$
– forest
14 hours ago