Am Freitag 19 März 2021 08:24:53 schrieb Werner Koch via Gnupg-users:
> On Fri, 19 Mar 2021 01:50, Ángel said:
> > The FAQis outdated. GnuPG was indeed updated some years ago to use 3072
> > as the default size for rsa
>
> Actually 7 months:
> Noteworthy changes in version 2.2.22 (2020-08-27)
>
On Fri 2021-03-19 15:30:51 -0700, Mark via Gnupg-users wrote:
> It also has issues with signed messages and lists. For example you
> signed this message but it says "uncertain digital signature". I don't
> remember this being an issue in the older TB/Enigmail.
Signed messages on mailing lists
On Fri 2021-03-19 08:29:12 +0100, Werner Koch via Gnupg-users wrote:
> You may also skip the menu thing and use
>
> gpg --quick-gen-key b...@example.com future-default
I agree with Werner's recommendation of using --quick-gen-key and
future-default.
If you're going to provide an e-mail
It also has issues with signed messages and lists. For example you
signed this message but it says "uncertain digital signature". I don't
remember this being an issue in the older TB/Enigmail.
On 3/19/2021 10:42 AM, Werner Koch via Gnupg-users wrote:
On Fri, 19 Mar 2021 03:33, Robert J. Hansen
It "does and it doesn't" I have some that were created in Kleopatra and
then imported into Thunderbird 78. As for creating them, no You
don't get to choose any options when generating ECC keys.
On 3/19/2021 12:33 AM, Robert J. Hansen via Gnupg-users wrote:
The next default is ECC
On Fri, 19 Mar 2021 03:33, Robert J. Hansen said:
> Last I checked, Thunderbird 78 did not support ed25519+cv25519
> keys. That's not a niche implementation.
I did extensive test with Ribose to make sure that RNP (the crypto
engine now used by TB) is compatible with GnuPG. Thus I wonder why TB
On Fri, 19 Mar 2021 08:33:17 +0100,
Robert J. Hansen via Gnupg-users wrote:
>
> > The next default is ECC (ed25519+cv25519) which is supported by most
> > OpenPGP implementations. Only if you have a need to communicate with
> > some niche implementaions you need to use rsa3072.
>
> Last I
The next default is ECC (ed25519+cv25519) which is supported by most
OpenPGP implementations. Only if you have a need to communicate with
some niche implementaions you need to use rsa3072.
Last I checked, Thunderbird 78 did not support ed25519+cv25519 keys.
That's not a niche implementation.
On Thu, 18 Mar 2021 19:34, David Mehler said:
> in the output there's ECC output should I go with an ECC-style key or
> RSA? As regards RSA keysize I typically use 4096.
The next default is ECC (ed25519+cv25519) which is supported by most
OpenPGP implementations. Only if you have a need to
On Fri, 19 Mar 2021 01:50, Ángel said:
> The FAQis outdated. GnuPG was indeed updated some years ago to use 3072
> as the default size for rsa
Actually 7 months:
Noteworthy changes in version 2.2.22 (2020-08-27)
-
* gpg: Change the default key
I'd like to know current best practices for obtaining a new one?
This question gets asked so often that it has its own FAQ entry. Yes,
parts of the FAQ are outdated, but this particular one is very current.
https://www.gnupg.org/faq/gnupg-faq.html#tuning
* You don't need to "tune&q
Reading the URLs given by the OP, I see that the GPG FAQ (1) talks about
a default of '2048' but in the latest (2.2.17) release of GPG it looks
like the default is now '3072':
Yep.
[puts on maintainer hat]
The last time I suggested revisions to that text there was no community
consensus on
On 2021-03-18 at 15:15 +0100, john doe via Gnupg-users wrote:
> Reading the URLs given by the OP, I see that the GPG FAQ (1) talks
> about a default of '2048' but in the latest (2.2.17) release of GPG
> it looks like the default is now '3072':
> What keysize do you want? (3072)
>
>
> Am I
.
Dave.
On 3/18/21, Werner Koch wrote:
> On Thu, 18 Mar 2021 00:06, David Mehler said:
>
>> My existing GPG certificate is going to expire in less than a month.
>> I'd like to know current best practices for obtaining a new one? In
>
> Do you really want a new one? Usually
On Thu, 18 Mar 2021 00:06, David Mehler said:
> My existing GPG certificate is going to expire in less than a month.
> I'd like to know current best practices for obtaining a new one? In
Do you really want a new one? Usually it is easier to prolong your key.
By default a new key has an
On 3/18/2021 2:39 PM, Andreas K. Huettel wrote:
https://www.gentoo.org/glep/glep-0063.html
https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys
Reading the URLs given by the OP, I see that the GPG FAQ (1) talks about
a default of '2048' but in the latest
https://www.gentoo.org/glep/glep-0063.html
https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys
> On the pages, I get 'There is currently no text in this page. You can
> search for this page title in other pages, or ...'.
> Am I missing something?
Only that
On 3/18/2021 10:21 AM, Andreas K. Huettel wrote:
Hi David,
when Gentoo switched to requiring gpg-signed git commits and pushes, we put
some thought into requirements and best practices. Minus the Gentoo-specific
parts, this is probably good reading:
https://www.gentoo.org/glep/glep-0063.html
Hi David,
when Gentoo switched to requiring gpg-signed git commits and pushes, we put
some thought into requirements and best practices. Minus the Gentoo-specific
parts, this is probably good reading:
https://www.gentoo.org/glep/glep-0063.html
https://wiki.gentoo.org/wiki
Hello,
My existing GPG certificate is going to expire in less than a month.
I'd like to know current best practices for obtaining a new one? In
particular I'm looking for the best protocol and strength for a
security not a performance stance. The certificate will mainly be used
for verifying
FWIW I distrust encrypted drives using hardware encryption. This came out
just a few days ago:
https://thehackernews.com/2018/11/self-encrypting-ssd-hacking.html: Flaws
in Popular Self-Encrypting SSDs Let Attackers Decrypt Data.
On Tue, Nov 6, 2018 at 10:15 PM Nicholas Papadonis <
Ditto,
But don’t tell the Australian Government, it’s probably on their back door
request list…;)
> On 8 Nov 2018, at 01:26, Bear Giles wrote:
>
> FWIW I distrust encrypted drives using hardware encryption. This came out
> just a few days ago:
>
Interesting. How about this for a start?
http://nickpapadonis.com/images-share/summerian-ancient-mesopotamia-ancient-lock.jpg
http://nickpapadonis.com/images-share/anunnaki1.jpg
http://nickpapadonis.com/images-share/summerian-Winged_Human-headed_Bulls.JPG
On Sun, Nov 4, 2018 at 7:21 PM
Hi!
Please do not post commercial advertisements to a gnupg mailing list.
There is no problem to _mention_ proprietary software on the GnuPG lists
if that mentioning is related to technical questions. But sales pitch
or ads are unwanted.
Thanks,
Werner
ps.
I removed the openssl list from
Hi Nick
Have You tried The FooKey Method ? https://foocrypt.net/the-fookey-method
Also,
I will be sourcing public addendum's as addendum's to my submission into the
Parliamentary Joint Committee on Intelligence and Security [
Try openssl cms ( as newer alternative to s/mime)
пт, 2 нояб. 2018 г. в 23:30, Nicholas Papadonis :
>
> Security Experts,
>
> I'm considering encrypting a tar archive and optionally a block file system
> (via FUSE) using either utility. Does anyone have comments on the be
Security Experts,
I'm considering encrypting a tar archive and optionally a block file system
(via FUSE) using either utility. Does anyone have comments on the best
practices and tools for either?
I read that the OpenSSL AES-CBC CLI mode is prone to a malleable attack
vector and it's CLI
> From: openssl-users on behalf of Nicholas
> Papadonis
> Sent: Friday, November 2, 2018 14:29
> I read
Where? It's hard for us to determine the quality of your source, or your
interpretation of it, if we don't know what it is.
> that the OpenSSL AES-CBC CLI mode is prone to a malleable
On 27/11/15 12:41, Andrew Gallagher wrote:
> There's a post about how to do this in the list archives:
>
> https://lists.gnupg.org/pipermail/gnupg-users/2009-May/036505.html
Thanks for the pointer!
> ... but it's really not worth your while. So long as your primary key
> doesn't have E usage
On 23/11/15 21:31, James wrote:
> It appears that information I had read previously was erroneous. I was
> under the impression the capabilities (at least for the primary key)
> were set in stone, hence my apprehension at avoiding those insatiable
> knobs and gears I like to tinker with. ;)
Well,
Thank you Robert and Peter.
It appears that information I had read previously was erroneous. I was
under the impression the capabilities (at least for the primary key)
were set in stone, hence my apprehension at avoiding those insatiable
knobs and gears I like to tinker with. ;)
This thread has
ding these questions is greatly appreciated.
James
1 https://help.riseup.net/en/security/message-security/openpgp/best-practices
On Wed, Nov 18, 2015 at 7:35 PM, da...@gbenet.com <da...@gbenet.com> wrote:
> On 18/11/15 12:08, Peter Lebbing wrote:
>> On 17/11/15 15:33, Andrew Gallaghe
Robert,
I appreciate the input and hear you loud and clear.
I respect that GPG makes sane, technically secure and well-thought-out
decisions. As I mentioned in my previous response, the folks that
designed and coded GPG are likely far more intelligent than I. This
does not assuage my deep
> The same can be said for almost any complex system, software or not.
Absolutely. Please don't misinterpret what I said as trying to dissuade
you from curiosity. I'm just urging you to not let your curiosity lead
you into making poor decisions from the get-go.
The following anecdote is
On 23/11/15 17:20, James wrote:
> If you create a primary key, upload it to a public
> keyserver and later decide: "hrm, my public key should really only
> certify, not sign," it's a bit too late. (although not impossible,
> difficult to change ex post facto).
Okay, so let me answer this one
> - I believe that GPG has sane settings out-of-the-box, but prefer to
> verify that trust. ;) Why doesn't GPG set the digest algorithm to
> SHA512 instead of 256 out of the box?
For the same reason it doesn't default to RSA-4096: because the authors
are unconvinced there's a need. Longer is not
> compromised?"
>
> Seems to me that the primary key /should/ have both certify and sign
> capabilities to really be useful, no?
>
> Any thoughts and ideas regarding these questions is greatly appreciated.
>
> James
>
> 1
> https://help.riseup.net/en/security/me
On 17/11/15 15:33, Andrew Gallagher wrote:
>> https://alexcabal.com/creating-the-perfect-gpg-keypair/
>
> This is a fairly good article - I've used it myself for reference in the
> past. Also have a look at:
I disagree, I'd recommend people not to read that article, let alone
follow its advice.
> Is this accurate?
Not really, no.
One of the weirdest things about OpenPGP (and, by extension, GnuPG) is
that it provides a great deal of mechanism and very little in the way of
policy. As a result, it's incredibly difficult to speak about best
practices in specific terms. What's g
On 11/17/2015 1:32 PM, James wrote:
> All,
>
> I'm just dipping my toes into GPG and am making a significant effort
> to "do things right" out of the gate.
Welcome!
> Based on my research, it is my understanding that "best practices"
> dictate we s
On 17/11/15 12:32, James wrote:
>
> Based on my research, it is my understanding that "best practices"
> dictate we should have one master key with subkeys for specific
> purposes (personal work, "work" work, etc.). The master key is kept on
> an "offlin
All,
I'm just dipping my toes into GPG and am making a significant effort
to "do things right" out of the gate.
Based on my research, it is my understanding that "best practices"
dictate we should have one master key with subkeys for specific
purposes (personal wo
arguing about *do*
*not* *matter*. And passionate argument about things that don't matter
is... bikeshedding.
No more bikeshedding. My final statements about this thread:
* I've seen very little support from the list for your proposed
best practices document,
* I conclude the community's
preferences except for 3DES, Bob's personal-cipher-preferences will take
precedence in the messages that he sends.
I feel like i shouldn't have to point this out, but:
* This is what the best practices page we've been discussing is suggesting.
This is the right thing to do, and Bob should do
I think you're talking about personal-cipher-preferences here, which
Alice uses to govern the cipher she uses.
Correct.
Note that she could even put IDEA first here.
Sure, but it wouldn't take unless Bob had IDEA in his preference list.
If Bob's preference list is AES256 CAMELLIA256 3DES,
On 07/04/2014 12:08 AM, Robert J. Hansen wrote:
Bob is all about I must have at least 256 bits of keyspace in all my
email! But Bob can't do that, because Alice can *always* degrade him
to 112 bits by choosing 3DES.
Of course. And Alice can always send Bob cleartext too. does that mean
that
Of course. And Alice can always send Bob cleartext too. does that mean
that Bob shouldn't offer any encryption key at all because there's no
guarantee that it will be used?
It means Bob should have a line item for that in his security model.
Alice may send me cleartext.
It also means Bob
On Sat, 28 Jun 2014 22:47, vmaa...@gmail.com said:
I'm using the FSFE card [1] with SCR3500 [2]. Ok yeah sure, that’s a
fellowship card but I actually also wanted to point out the SCR3500
Right. Some friends told me that this works really well for them. BTW,
the fellowship card is exactly the
On Fri, 27 Jun 2014 21:44, ds...@jabberwocky.com said:
I do admire the Neo form factor though.
The SCT3512 [1] with an OpenPGP card is also quite convenient:
http://werner.eifzilla.de/sct3512.jpg
I have taken off the ID-000 form factor card for the picture. The label
is also non-standard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Friday 27 June 2014 at 11:35:00 PM, in
mid:a2f8dba9-1da7-47a6-bc79-cfaea3b02...@jabberwocky.com, David Shaw
wrote:
Incidentally, since subkeys have come up in this
thread, I seem to recall a few strange bugs with 8.x
(8.0? 8.1?) that
On Jun 28, 2014, at 5:20 AM, MFPA 2014-667rhzu3dc-lists-gro...@riseup.net
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Friday 27 June 2014 at 11:35:00 PM, in
mid:a2f8dba9-1da7-47a6-bc79-cfaea3b02...@jabberwocky.com, David Shaw
wrote:
Incidentally, since subkeys
On Sat, Jun 28, 2014 at 9:18 AM, Werner Koch w...@gnupg.org wrote:
On Fri, 27 Jun 2014 21:44, ds...@jabberwocky.com said:
I do admire the Neo form factor though.
The SCT3512 [1] with an OpenPGP card is also quite convenient:
http://werner.eifzilla.de/sct3512.jpg
I have taken off the
I'm using the FSFE card [1] with SCR3500 [2]. Ok yeah sure, that’s a fellowship
card but I actually also wanted to point out the SCR3500 which is a nice
similar form factor option for a reader.
https://www.dropbox.com/s/jbaxi8ulfdz5585/fsfe_with_scr3500.jpg
[1]
On Thu, 26 Jun 2014 23:36, r...@sixdemonbag.org said:
on the key. For any OpenPGP certificate, you can send it 3DES-encrypted
traffic and be in complete accordance with the spec and the recipient's
preferences.
Assuming the sender uses a decent implementation, the attacker must have
been
Robert J. Hansen:
On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote:
PGP 8 was released over a decade ago, that's hardly a modern
implementation:
And yet, it still conforms (largely) to RFC4880. Methinks you're
objecting because it's a largely-conforming implementation that doesn't
have
On 6/27/2014 at 9:59 AM, shm...@riseup.net wrote:
is it really a case of obdurateness, if it ain't broke don't fix
it,
or an unwillingness to use and get accustomed to something new
and/or
different, perhaps a new gui - look, i completely sympathise with
the
latter especially for older people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/27/2014 03:54 PM, shm...@riseup.net wrote:
Robert J. Hansen:
On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote:
PGP 8 was released over a decade ago, that's hardly a modern
implementation:
And yet, it still conforms (largely) to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Friday 27 June 2014 at 3:57:25 PM, in
mid:53ad8655.4090...@sumptuouscapital.com, Kristian Fiskerstrand
wrote:
You won't convince a corporate IT department in a Law
firm (or for that matter Financial world) about it.
They want SLAs and
On 26.06.2014 23:28, Paul R. Ramer wrote:
On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
As for arguments about use on smartcards -- if you plan to get a
smartcard, and you have a primary key that is too large for it, you
can always generate and publish
On Jun 27, 2014, at 6:45 AM, Viktar Siarheichyk v...@eq.by wrote:
On 26.06.2014 23:28, Paul R. Ramer wrote:
On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor
d...@fifthhorseman.net wrote:
As for arguments about use on smartcards -- if you plan to get a
smartcard, and you have a primary
Kristian Fiskerstrand wrote:
On 06/27/2014 03:54 PM, shm...@riseup.net wrote:
Robert J. Hansen:
On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote:
PGP 8 was released over a decade ago, that's hardly a modern
implementation:
And yet, it still conforms (largely) to RFC4880. Methinks
My understanding is that the YubiKey Neo applet supports up to 2048 bit RSA.
Thus there are some keys that will work with the V2 SmartCard but not on the
Neo.
Yes limitation is physical, the ship cannot have key size more than 2048 bit
RSA on Yubikey, for the V2 SmartCard GnuPG, it's
On 6/27/2014 3:14 AM, Werner Koch wrote:
Assuming the sender uses a decent implementation, the attacker must have
been able to modify the senders system by changing the code or the
config files.
Nope.
It took me about fifteen seconds to come up with a way to do this with
acceptable (if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/27/2014 10:24 PM, John Clizbe wrote:
Kristian Fiskerstrand wrote:
On 06/27/2014 03:54 PM, shm...@riseup.net wrote:
Robert J. Hansen:
On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote:
PGP 8 was released over a decade ago, that's hardly
On Jun 27, 2014, at 4:24 PM, John Clizbe j...@enigmail.net wrote:
Kristian Fiskerstrand wrote:
On 06/27/2014 03:54 PM, shm...@riseup.net wrote:
Robert J. Hansen:
On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote:
PGP 8 was released over a decade ago, that's hardly a modern
Since it looks as if I'm going to be out of contact for the next few
days (traveling), I figured I'd share the degradation a little early --
Alice and Bob are communicating. Bob insists on using extremely large
keyspaces: his certificate is RSA-16384 and his preference list is
AES256
On Wed, 25 Jun 2014 21:53, joh...@vulcan.xs4all.nl said:
While important I don't loose a night's sleep over a DOS attack. It's
annoying but it doesn't reveal any confidential information.
Nor do I. However, such a simple DoS is generally consideres a security
bug and thus you should better
MFPA:
Hi
On Tuesday 24 June 2014 at 8:37:30 PM, in
mid:53a9d37a@vulcan.xs4all.nl, Johan Wevers wrote:
Al Quaida use horse couriers who memorise the
message, the American's could not intercept them.
Even if they did intercept them, are the Americans any good at
interrogating
to do enhanced equine interrogation.
Ah, yes... the fetish of equinonecroflagellation. It has an strikingly common
rate of incidence with maxicryptosizism[*], along with Internet posts labeling
the author[s]'s opinions vis-a-vis cryptography usage as Best Practices.
I have found the best way to handle
Ah, yes... the fetish of equinonecroflagellation. It has an strikingly common
rate of incidence with maxicryptosizism...
Although I'm going to be (almost wholly) agreeing with John here, I'm
speaking just for myself. If anyone wants to chime in with a
d'accord, that's on them. :)
What gets
On 06/26/2014 04:26 PM, Robert J. Hansen wrote:
Ah, yes... the fetish of equinonecroflagellation. It has an
strikingly common rate of incidence with maxicryptosizism...
Although I'm going to be (almost wholly) agreeing with John here,
I'm speaking just for myself. If anyone wants to chime
While in principle I agree that 2048 bit key is strong enough for most
uses, comparing 3DES keys space (or any other symmetric encryption
algorithm) and RSA (or some other public key system) key space is a
bit like comparing apples and oranges. If you crack the 3DES
encryption of a message
On 06/25/2014 02:25 AM, Werner Koch wrote:
This misunderstanding is actually an indication of the problem. You are
talking 4096 vs. 2048 while the more important case is to read the
security announcements and update your gpg.
That's a great point. I've just proposed a pull request on that
On 06/26/2014 10:26 AM, Robert J. Hansen wrote:
So in a very real sense, anything past RSA-2048 is at best a you
*might* get some additional security, depending on what symmetric
algorithm your correspondent uses. Oh, and you can't forbid your
correspondent from using 3DES, either.
Of course
The goal of this document is to encourage people to make sure that
crypto is not the weak point in their communications.
If that's your criteria, RSA-1024 is sufficient. Real systems are so
exploitable that crypto is never the weak point.
Please read Bernstein's paper suggesting larger
On 06/24/2014 07:28 AM, Gabriel Niebler wrote:
I consider myself quite the amateur (I haven't even read most of RFC
4880 yet), but I do take issue with one point in the riseup.net Best
Practices page, namely the bit where it says self-signatures must not
use SHA1.
I find that statement too
On 6/26/2014 11:26 AM, Daniel Kahn Gillmor wrote:
The pushback of don't bother using stronger crypto, something else
will be your problem seems silly to me. It's like saying don't
bother fighting sexism, people are going hungry! We can (and
should) push on all of these fronts concurrently.
Am Do 26.06.2014, 16:06:25 schrieb Robert J. Hansen:
Since it's possible to degrade the cipher preference to 3DES,
we need to assume that's exactly what will happen. (Your next
objection is How?. That's a non-sequitur right now. I believe
serious adversaries can do this because (a) there's
On June 26, 2014 8:26:16 AM PDT, Daniel Kahn Gillmor d...@fifthhorseman.net
wrote:
As for arguments about use on smartcards -- if you plan to get a
smartcard, and you have a primary key that is too large for it, you can
always generate and publish new subkeys that will fit in your
smartcard.
If
On 6/26/2014 4:35 PM, Hauke Laging wrote:
You mean except for that you must be capable of forging a mainkey
signature (if you don't control the sending system anyway in which case
you don't need the key any more)?
Nope. :) I meant what I said.
The preference list on the key is advisory,
On 6/26/2014 2:25 PM, Daniel Kahn Gillmor wrote:
If you know of a modern OpenPGP implementation that supports SHA-1 but
not SHA-256 or SHA-512, please point it out (and no, creating one just
to be able to point to it doesn't count :P)
PGP 8.x, which is still in use today by a surprising number
On 06/26/2014 05:45 PM, Robert J. Hansen wrote:
On 6/26/2014 2:25 PM, Daniel Kahn Gillmor wrote:
If you know of a modern OpenPGP implementation that supports SHA-1 but
not SHA-256 or SHA-512, please point it out (and no, creating one just
to be able to point to it doesn't count :P)
PGP 8.x,
On 6/26/2014 5:57 PM, Daniel Kahn Gillmor wrote:
PGP 8 was released over a decade ago, that's hardly a modern
implementation:
And yet, it still conforms (largely) to RFC4880. Methinks you're
objecting because it's a largely-conforming implementation that doesn't
have good support for SHA256.
On Tue, 24 Jun 2014 21:35, joh...@vulcan.xs4all.nl said:
Finally upgrade that 286 to DOS 3.0? If you have a system that can't
handle 4k keys you have very specific needs. Sending a lot of messages
This misunderstanding is actually an indication of the problem. You are
talking 4096 vs. 2048
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Tuesday 24 June 2014 at 8:37:30 PM, in
mid:53a9d37a@vulcan.xs4all.nl, Johan Wevers wrote:
Al Quaida use horse couriers who memorise the
message, the American's could not intercept them.
Even if they did intercept them, are the
On 25-06-2014 8:25, Werner Koch wrote:
This misunderstanding is actually an indication of the problem. You are
talking 4096 vs. 2048 while the more important case is to read the
security announcements and update your gpg.
While important I don't loose a night's sleep over a DOS attack. It's
On 25-06-2014 21:51, MFPA wrote:
Even if they did intercept them, are the Americans any good at
interrogating a horse?
I don't know, but torturing the courtier turned out to be unreliable at
best.
--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html
Even if they did intercept them, are the Americans any good at
interrogating a horse?
Yes. We are world champions at beating dead horses. To interrogate a
horse, first simply shoot it in the head, and then we can leverage our
dead-horse-beating skills in order to do enhanced equine
On Tue, 24 Jun 2014 05:55, fr...@frase.id.au said:
rounds today. Quite a lot of good info, especially regarding key
strength and expiry, and digest preferences.
Just for the records: _I_ do not consider the use of a 4096 bit RSA key
and a preference for SHA-512 a best practice. For a secure
I was going to create a new PGP key myself by following that article.
Werner, do you have any more input or comments to add regarding that
article? I am curious to hear input from multiple sources/people.
On 6/24/14, Werner Koch w...@gnupg.org wrote:
On Tue, 24 Jun 2014 05:55,
On Tue, 24 Jun 2014 11:42, p...@heypete.com said:
Would SHA-256 be a better (in the context of being more compatible)
choice if one preferred using a non-SHA-1 hash?
At least on 32 bit machines SHA-256 is faster than SHA-512. Some CPUs
have hardware support for SHA-256 but not for SHA-512.
consider myself quite the amateur (I haven't even read most of RFC
4880 yet), but I do take issue with one point in the riseup.net Best
Practices page, namely the bit where it says self-signatures must not
use SHA1.
I find that statement too strong.
AFAICS this will lead to keys which may
Just for the records: _I_ do not consider the use of a 4096 bit RSA key
and a preference for SHA-512 a best practice.
I'll go one step further: I think the article is going to do more harm
than good.
When young people ask me where to begin programming, I tell them to just
begin. Don't worry
I recently, generated a new keypair (GPG4win), and the defaults presented where
RSA/2048. I did, some digging around on the RSA vs DSA thing and RSA still seems
to be the recommended way to go, the only thing I did was up my key size to
4096 I left all the other defaults.
On Monday,
I just finished reading the article, I don't know anyone who does all of those
things. most people I know
who are advid GPG users, gen a key, maybe a revoke, upload it to a keyserver
sometimes. and that's about it.
using subkeys, offline keys etc, adds way more complexity to something arguably
I recently, generated a new keypair (GPG4win), and the defaults
presented where RSA/2048. I did, some digging around on the RSA vs DSA
thing and RSA still seems
to be the recommended way to go, the only thing I did was up my key size
to 4096 I left all the other defaults.
This depends on
Am Di 24.06.2014, 09:50:04 schrieb Nex6|Bill:
anykind of best practice, should
be simple, so that it encourages a sane baseline for people.
That depends on it whether you need security or the illusion of security
is enough for you.
IMHO it is one of the main problems that hardly anyone cares
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/24/2014 10:52 AM, Robert J. Hansen wrote:
I recently, generated a new keypair (GPG4win), and the defaults
presented where RSA/2048. I did, some digging around on the RSA
vs DSA thing and RSA still seems to be the recommended way to go,
the
illusionary security from that? and while
I agree that security is not well defined, in a way that a user or
admin can tell what level of security an object or configuration will
give him.
that does not mean we should get all hyper paranoid on all of our best
practices and guidelines to a point where
On 24-06-2014 8:47, Werner Koch wrote:
How does a help 4096 key help if I can send you an encrypted mail which
will lock up your MUA until you kill it
Finally upgrade that 286 to DOS 3.0? If you have a system that can't
handle 4k keys you have very specific needs. Sending a lot of messages
1 - 100 of 185 matches
Mail list logo
