automatically. I use Thunderbird with Enigmail
and it will encrypt an attachment to an encrypted email without any
additional configuration or installation of libraries.
Regards,
Ben
--
Ben McGinnes http://www.adversary.org/ Twitter: benmcginnes
Systems Administrator, Writer, ICT Consultant
is an awesome combo.
It most certainly is, especially with platform independence. It's
particularly nice to be able to copy profile directories between systems
which will preserve plugins (I primarily use Enigmail and External
Editor) across those platforms.
Regards,
Ben
--
Ben McGinnes http
On 15/10/10 9:11 AM, MFPA wrote:
El 14-10-2010 16:58, Remco Rijnders escribió: ...
I guess it would just have been nice if there was an email address you can
send a sign up message to, confirm your email address, and be part of the
group, similar to how mailing lists like this one work,
On 12/11/10 9:01 PM, Reinhard Irmer wrote:
I have installed GnuPG 1.4.11 from the GnuPT-site and GnuPG 2.0.16 (gpg4win
2.1.0ß) under winxp. codepage is 437. The verify-result is OK in both
versions, but only the umlauts are making trouble:
In Gpg v1.4 it looks like
On 14/11/10 8:52 PM, Reinhard Irmer wrote:
you wrote on So, 14.Nov.2010 (02:13:47):
You should be able to change the Thunderbird setting to UTF-8 and make
it behave in View - Character Encoding.
View utf-8: umlauts in body or utf-8-characters in body are OK,
umlauts in headerpane are
On 15/11/10 7:01 AM, Reinhard Irmer wrote:
I'm not so familiar with TB because my favourite client is
40tude-dialog, where everything works fine. I only tested the probs
with TB to see,if there are differences in showing the characters. I
had set the options in TB for incoming/outgoing msgs.
On 21/11/10 12:36 AM, Gold IsMoney wrote:
The issue is obvious - if it doesn't ask me for my password when
sending e-mails, it means that anyone with access to my pc can go
into Thunderbird and send encrypted e-mails, using my identity. Is
this a bug, or is there some configuration
On 24/11/10 10:35 PM, Aaron Berthold wrote:
In the last few months, I've become comfortable enough with GnuPG (using
TB+Enigmail) for personal, small scale use but there are a couple of use
cases I've yet to find good solutions to. I figured the people here on
the List would know. ^_^
The
On 25/11/10 5:05 AM, Michael Fladerer wrote:
The gpg manpage says:
(...)
--keyring file
Add file to the current list of keyrings. (...)
If the intent is to use the specified keyring alone, use --keyring
along with --no-default-keyring.
HTH.
Oh, cool, thanks.
Hello,
I've been set some mail using an old, but still valid key,
using IDEA. The last time I used IDEA was a long time ago and now
I've finally found the need to compile it for my current system.
The problem is that it doesn't seem able to compile on my MacBook Pro
(OS X 10.5.8). It
On 26/11/10 6:00 PM, I wrote:
So, my question is what do I need to add or tweak to fix this?
The answer, it seems, is don't try to tweak anything. Instead do a
completely fresh extraction and installation from source, no messing
around with make clean and reconfiguring in a previously
Hello,
I am giving very serious thought to creating new keys and
doing a (long-term) transition to them. This is partly to respond to
known flaws with SHA-1 and take advantage of SHA-256 and higher.
There is currently a push to move away from SHA-1 usage by the end of
2010, although it
On 10/12/10 1:08 AM, Robert J. Hansen wrote:
On 12/9/2010 1:14 AM, Ben McGinnes wrote:
I am giving very serious thought to creating new keys and
doing a (long-term) transition to them. This is partly to respond to
known flaws with SHA-1 and take advantage of SHA-256 and higher.
My best
On 10/12/10 3:58 AM, J. Ottosson wrote:
On 10 Dec 2010 at 2:55, Ben McGinnes wrote:
As the smartcard isn't on the agenda for me at all, I'll base my
decision on security rather than convenience.
If smartcard is not on your agenda you are certainly not basing your
decision on security
On 10/12/10 4:25 AM, Grant Olson wrote:
Right. If the hash algo is your only concern, you can just change
that. No need to regenerate a key, unless you're just using that as
an motivator to bump up your key-size and/or create an offline
primary key.
I've already switched the hash
On 10/12/10 4:38 AM, Hauke Laging wrote:
Am Donnerstag 09 Dezember 2010 18:18:00 schrieb Ben McGinnes:
And you're basing that assessment on what?
I know where all the physical media containing a copy of my secret
key(s) are and I control all the hardware that can access them
On 10/12/10 5:01 AM, Daniel Kahn Gillmor wrote:
On 12/09/2010 09:08 AM, Robert J. Hansen wrote:
On 12/9/2010 1:14 AM, Ben McGinnes wrote:
I am giving very serious thought to creating new keys and
doing a (long-term) transition to them. This is partly to respond to
known flaws with SHA-1
to 160 bits.
Well, I changed the prefs on my key to this:
[ultimate] (1). Ben McGinnes b...@adversary.org
Cipher: AES256, TWOFISH, CAMELLIA256, AES192, CAMELLIA192, AES,
CAMELLIA128, 3DES, CAST5, BLOWFISH, IDEA
Digest: SHA512, SHA384, SHA256, SHA224, RIPEMD160, SHA1, MD5
Compression
On 10/12/10 6:12 AM, Daniel Kahn Gillmor wrote:
On 12/09/2010 01:30 PM, Ben McGinnes wrote:
Ah, a debate, excellent. Now let's make it a little more
entertaining,
:P
I'm glad I'm not the only one who likes to find answers this way. :)
RIPEMD-160 is another 160-bit hash, same size as SHA
On 10/12/10 6:42 AM, Robert J. Hansen wrote:
On 12/9/10 2:33 PM, Ben McGinnes wrote:
Yet it still ignores everything which precedes RIPEMD160, presumably
because it's a DSA1 key and can't handle the SHA-2 digests.
This is premature.
It could be any of the following:
* You do not have
On 10/12/10 6:17 AM, Robert J. Hansen wrote:
On 12/9/10 1:30 PM, Ben McGinnes wrote:
Ah, a debate, excellent. Now let's make it a little more
entertaining, where do you see RIPEMD-160 in the scheme of things?
My suspicion is RIPEMD-160 is broken, we just don't know how. It
has an awful
On 10/12/10 6:22 AM, J. Ottosson wrote:
But you do know what purpose a smartcard type of device is for, right?
Yep, they were standard issue when I worked at Sun.
Protection of some kind of data, most often a key or several of
them. We use hardware security devices of various sorts in many
On 10/12/10 7:48 AM, Daniel Kahn Gillmor wrote:
On 12/09/2010 03:09 PM, Ben McGinnes wrote:
Is this why a revoked key can still be used to decrypt data that was
encrypted with a non-revoked copy of the key?
the things that get revoked are OpenPGP certificates. the certificates
themselves
On 10/12/10 8:33 AM, John Clizbe wrote:
Ben McGinnes wrote:
On 10/12/10 6:17 AM, Robert J. Hansen wrote:
On 12/9/10 1:30 PM, Ben McGinnes wrote:
Is it possible that this current transition push is partially aimed
at reigniting the WG's discussion by creating a new de-facto
standard?
Dunno
On 10/12/10 9:28 AM, John Clizbe wrote:
Robert J. Hansen wrote:
On 12/9/10 1:30 PM, Ben McGinnes wrote:
If/when the time comes for SHA-1 to be completely removed from OpenPGP,
the migration path will quite likely involve new keys -- the same way
that the V3/V4 migration path in the past
On 10/12/10 9:32 AM, John Clizbe wrote:
Ben McGinnes wrote:
Thanks. I think I'll lurk for a bit before I start causing trouble,
though. ;)
You should also be able to download the complete archives of the
list in mbox format for review. If not, write to me off-list and
I'll see what I
On 10/12/10 9:51 AM, John Clizbe wrote:
If one is still using keys of the old signing default of DSA/1024, a
160-bit hash is the only choice available. That's dictated by the
standard.
That's what I've got.
But there's no pressing need to generate a new key -- one
can just switch to using
On 10/12/10 10:57 AM, Robert J. Hansen wrote:
On 12/9/2010 6:49 PM, Ben McGinnes wrote:
Just to clarify, does this mean that SHA-256 or 512 (or whatever)
truncated to 160-bits prevent the potential collision attacks that
might be able to be launched against SHA-1?
Correct. Truncating
On 10/12/10 10:55 AM, Robert J. Hansen wrote:
On 12/9/2010 6:18 PM, Ben McGinnes wrote:
The last bit of documentation I saw on ECC is a little old and stated
that it wasn't well known enough to consider using. I guess that's
changed now.
Back in 2000 or so, the consensus was that ECC
On 10/12/10 11:16 AM, David Shaw wrote:
Yes, but at the risk of pedantry:
I'd rather the accuracy of pedantry than be mired in uffish thought.
The attacks against SHA-1 haven't been extended to the SHA-2 family
yet. By truncating a SHA-2 to 160 bits, you're creating a
non-broken (for now)
On 10/12/10 3:32 PM, Robert J. Hansen wrote:
I find this to be a useful exercise. Your mileage may, and probably
will, vary. If you have a very well-developed WoT and don't want to
jeopardize breaking other people's WoTs, then you might not want to do
this. :)
It certainly looks useful
On 10/12/10 2:33 PM, David Shaw wrote:
A good way to look at this is to pick what you want your primary key
to be. The subkeys don't really matter that much, as the primary is
the one that gathers signatures, and the one that makes (i.e. signs)
subkeys. It's the key that establishes
On 12/12/10 6:07 AM, David Shaw wrote:
The flags you can turn on and off in expert mode are:
Sign: sign data (i.e. sign a file)
Encrypt: encrypt
Authenticate: prove your identity (for example, sign a challenge
token presented by a server so it will let you in)
Ah, this explains its use
On 12/12/10 7:21 AM, David Shaw wrote:
On Dec 11, 2010, at 2:55 PM, Ben McGinnes wrote:
Cool. On a tangential note, could this be used as a basis for
applying a PKI/WoT model to certification of SSL keys, rather than
relying on CAs?
Yes indeed. See http://web.monkeysphere.info
On 12/12/10 8:03 AM, David Shaw wrote:
GPG has an option to create a special key like this. Basically,
after you make your backup copy, run:
gpg --export-secret-subkeys (thekey) my-subkeys-only.gpg
Then delete the real secret key (make sure you have a backup!):
gpg
On 12/12/10 8:51 AM, David Shaw wrote:
On Dec 11, 2010, at 4:42 PM, Ben McGinnes wrote:
Cool. What difference (if any) does this make to the
generation/export of the public key? And, more to the point, is it
best to provide a public key block generated without the presence of
the primary
On 12/12/10 10:22 AM, MFPA wrote:
On Saturday 11 December 2010 at 7:55:25 PM, in
mid:4d03d72d.1000...@adversary.org, Ben McGinnes wrote:
I don't really want to hijack my own thread, but I've
always been deeply suspicious of the obvious money grab
of the CA system of (mainly website) SSL
On 13/12/10 9:59 AM, David Tomaschik wrote:
My guess is that it has something to do with the fact that this list
(bizarrely, IMO) uses reply to sender by default rather than reply to
list. Some MUAs may mangle the Message ID in such a case (when the list
email is manually specified).
This is
On 13/12/10 10:52 AM, Robert J. Hansen wrote:
I have *never* claimed that we shouldn't move away from SHA-1. Heck, I
was even the one who told the original poster to use enable-dsa2 in
order to get access to the stronger hash algorithms.
Actually, I'm pretty sure that recommendation
On 15/12/10 4:11 AM, Robert J. Hansen wrote:
There are a few of them on the keyservers, IIRC. Whether this is the
result of a deliberate and carefully chosen policy, or rampant paranoid
schizophrenia, is an open question...
They could be a result of using the old Cyber Knights Templar
On 15/12/10 5:12 AM, Robert J. Hansen wrote:
What tool was used really doesn't interest me very much -- you can
create them with GnuPG, too, if you're willing to tweak the source a
little bit.
True, that one just made it a lot easier for people who did not
realise how easy it is to tweak
On 16/02/11 9:40 AM, hare krishna wrote:
(a) What OS are you running? - UNIX
(b) Which version? - platform/SUNW,Sun-Fire-V490
There are multiple operating systems which will run on the V490,
including Solaris (of course) and OpenBSD. Send the output of uname
-a to the list if you
On 24/02/11 8:03 PM, Doug Barton wrote:
On 02/23/2011 22:26, Aaron Toponce wrote:
Given the release of v1.4.10, the SHA256 hashing algorithm is
preferred over SHA1. Yet, after updating my default preferences
with 'setpref' and signing some text, SHA1 is still used as the
default hashing
On 25/02/11 12:48 AM, Aaron Toponce wrote:
I wanted to avoid breaking from default, which was the main reason
for my post, but it appears that it's not possible if I want to use
the stronger hashes, which is fine. As long as I know the
limitations of my keys, and don't force preferences when
On 27/02/11 1:24 PM, Jameson Rollins wrote:
On Sat, 26 Feb 2011 21:02:08 -0500, Avi avi.w...@gmail.com wrote:
Why? Inline is simple and effective. I'm curious as to why you
feel MIME is so much better.
http://josefsson.org/inline-openpgp-considered-harmful.html
Thanks for the link.
I'd
On 27/02/11 3:28 PM, Doug Barton wrote:
If you look at the characteristics of the actual messages encrypted
mail is very similar whether it's in-line or MIME.
Exactly, the encrypted output in both methods uses base-64 encoding.
It's signed messages that make things interesting because the
On 28/02/11 12:35 PM, Robert J. Hansen wrote:
On Feb 27, 2011, at 5:17 PM, David Shaw wrote:
Can I see the HCI study that MIME attachments confuse people? ;)
I would love to see such a study. However, I never made that claim. :)
Someone else made the claim PGP/MIME is superior
On 28/02/11 2:02 PM, David Shaw wrote:
I'm not at all surprised that you had those results. A limited
subset of people have support for OpenPGP signatures. A limited
subset of those people actually verify signatures. A limited subset
of those people actually pay attention to what those
On 28/02/11 2:59 PM, Grant Olson wrote:
I've been toying with the idea of expiring my key and seeing how
long it takes for anyone to notice. In fact, I've just decided I
will do this sometime in the next year. It'll be interesting to see
how long it takes people to notice even after I've
On 1/03/11 1:20 PM, Grant Olson wrote:
I wouldn't mind testing to help out, but I'm not throwing away my
current key anytime soon.
Ah ha! Another hint about the scav hunt. ;)
More seriously, I've been through this discussion with MFPA before and
I can see some circumstances where his idea
On 1/03/11 9:33 AM, David Shaw wrote:
That experiment, while interesting, is not relevant to the real
Martin / fake Martin situation we've been talking about. If both
Real Martin and Fake Martin have the same secret key, then there is
no way to tell them apart using signatures.
Hang on,
On 2/03/11 8:20 AM, Ingo Klöcker wrote:
Of course, my experience is from a time when UTF-8 wasn't used in email.
But do the standard mail clients (Outlook, GMail, Thunderbird) really
default to UTF-8 nowadays? Expecting people to properly configure their
mail clients is an unrealistic
On 8/03/11 2:09 PM, Jean-David Beyer wrote:
I run Red Hat Enterprise Linux 5.6 (the latest of the RHEL5 series)
and they are only up to gnupg-1.4.5-14.el5_5.1, They will probably
not move up until RHEL 6 (that I believe has just recently come
out).
It has, a couple of months ago.
It looks
On 9/03/11 5:52 PM, Bernhard Kleine wrote:
Hi everybody,
I am using ubuntu 10.10, gpg and evolution. And I am reading this
mailing list for quite some time. Lately to read this list is a pain
since many keys are no longer found on the key server(s) I have entered
into the keyserver list and
On 9/03/11 2:44 AM, Johan Wevers wrote:
MFPA schreef:
Something that would not be necessary if the
underlying openPGP implementations could handle hashed
user IDs.
Isn't it much easier to use the key ID / signature for
that? You already have that.
I don't understand.
Use the keyID /
On 10/03/11 3:31 AM, Bernhard Kleine wrote:
Some strange things have happened:
first: on the interactive sks-keyservers.net page I looked up the
key A18A54D6 and it did not show any result. Afterwards I typed
olson grant and got several keys listed but not the one we have been
looking
On 10/03/11 12:24 AM, Robert J. Hansen wrote:
It seems like this is really close to asking for private stream
searching, which would be the next logical step -- some way for the
client to query the database for a record in such a way there is no
way for the database to know what was queried.
On 10/03/11 12:39 AM, Robert J. Hansen wrote:
4. My suspicion is the number of users covered by (2) is pretty
small.
Very probably, at least at the moment (for the reasons Hauke
mentioned).
My suspicion is the number of users impacted by (3) is pretty large.
Almost certainly.
My
On 10/03/11 11:03 AM, Hauke Laging wrote:
Am Mittwoch 09 März 2011 14:39:35 schrieb Robert J. Hansen:
As we all know you love anecdotal evidence, here's mine: You are
probably right but consider two points:
1) Today there is no use in obeying the (2) rules. If such a feature
is
On 10/03/11 12:12 PM, Jeffrey Walton wrote:
Imagine you are Tunisian or Libyan or some other nationality where
disagreeing with the regime might get you killed. Would you want
your name and email associated with another's keyring? Or would you
prefer anonymity?
Another perfectly good reason
On 10/03/11 2:10 PM, Robert J. Hansen wrote:
I think it should also be noted that if I was serious about trying to
overthrow a government, I'd create a bare certificate without a name or
an email address on it. I'd also use it as infrequently as possible and
try to avoid any technology more
On 10/03/11 4:20 PM, Robert J. Hansen wrote:
Some people think they're going to take over the People's Republic of
Berkeley in a military coup
Idiom note for non-Americans: the University of California at Berkeley
is often called, tongue-in-cheek, the People's Republic of Berkeley.
This is
On 10/03/11 4:17 PM, Robert J. Hansen wrote:
On 3/9/2011 10:42 PM, Ben McGinnes wrote:
Which brings us back to creating a pseudonym, using Tor (or other
anonymising services), getting a disposable mail drop (or using
alt.anonymous.messages) and going from there. At the bare minimum.
Which
On 10/03/11 12:46 AM, Hauke Laging wrote:
There are several advantages:
1) You don't reveal the social connections by signing keys. If you
want to validate a key by its signatures and see a signature of an
unknown key then there is (IMHO) no reason why you should know who
has certified
On 11/03/11 12:10 AM, Robert J. Hansen wrote:
Not at all. Every few days the keyserver network posts complete dumps
of all the certificates in the system. (Or, more accurately, various
people within the network do.) This exists so that new volunteers who
want to contribute their services
On 10/03/11 9:23 PM, Hauke Laging wrote:
Am Donnerstag 10 März 2011 06:17:25 schrieb Robert J. Hansen:
while you could conceivably come up with an email address with high
enough entropy, it's easier to just use anonymous services and
dead-drop emails.
Of course, you can create a key with
On 11/03/11 6:50 PM, Daniel Kahn Gillmor wrote:
On 03/11/2011 01:44 AM, Ben McGinnes wrote:
Ah, this is what I've been looking around for! For the sake of the
archives, how does one provide a non-exportable certification?
Obviously the export flag won't cut it.
non-exportable OpenPGP
On 12/03/11 12:33 AM, David Shaw wrote:
As a general rule, most gpg options can be shortened, so long as
they are still unique.
A bit like IOS commands, good to know.
So the real name for the option is export-local-sigs, but
export-local or even export-l is fine (and export would not be
On 12/03/11 12:33 AM, Robert J. Hansen wrote:
On 3/11/2011 1:07 AM, Ben McGinnes wrote:
Out of curiosity, how big is that now?
My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large.
That's smaller than I would have thought, but a *lot* larger than the
last time I checked
On 11/03/11 9:54 PM, Peter Pentchev wrote:
All the GnuPG command-line commands and options may be abbreviated to
a unique, unambiguous starting part of their names. Try gpg --clearsi
or gpg --cl, for instance :)
Excellent, thanks.
Regards,
Ben
signature.asc
Description: OpenPGP digital
On 12/03/11 11:56 PM, Charly Avital wrote:
Hi,
from Terminal, from two different keyservers:
(1) Barack Hussein Obama (PoC) preside...@casabranca.gov
1024 bit DSA key 76F5FE21, created: 2010-04-07
(2) Barack Hussein Obama (DOD) presid...@whitehouse.gov
1024 bit DSA
On 13/03/11 6:37 AM, MFPA wrote:
Whatever you do with user IDs is optional, since they are just a
free-text field. And of course a user wanting to make their key
match more searches could include extra UIDs with additional
hashes. For example John Smith john.smith...@example.com could
On 12/03/11 6:26 PM, John Clizbe wrote:
That's the SKS implementation of the key database. On top of the
keys, there are several other tables. Within each table there is
also empty space, most commonly space left at the end of a page.
The present size of just the raw keys -- like you would
On 13/03/11 7:24 AM, MFPA wrote:
Or simply use pgp-inline so that the disclaimer comes after the
signature.
Yes, this is a fine example of why in-line still has a place in the world.
Regards,
Ben
signature.asc
Description: OpenPGP digital signature
On 13/03/11 7:22 AM, Robert J. Hansen wrote:
On 3/12/2011 1:05 PM, MFPA wrote:
How does the WoT idea require me to know the names or email addresses
associated with the keys in the trust path? The text strings in User
IDs do not feature in the trust calculation.
Yes, in fact, they do.
In
On 13/03/11 6:37 AM, MFPA wrote:
Whatever you do with user IDs is optional, since they are just a
free-text field. And of course a user wanting to make their key
match more searches could include extra UIDs with additional
hashes. For example John Smith john.smith...@example.com could
On 13/03/11 5:32 PM, John Clizbe wrote:
Ben McGinnes wrote:
Thanks. I think I might have to play around with installing a local
server. I don't have a big enough link to run a public server, but
running a local one would probably serve as an interesting exercise.
I think that's my
On 13/03/11 10:42 PM, Jerry wrote:
On Sun, 13 Mar 2011 16:21:43 +1100
Ben McGinnes b...@adversary.org articulated:
Yes, this is a fine example of why in-line still has a place in the
world.
Actually, it is a fine example of users/MUAs not correctly
formatting e-mail messages thereby
On 14/03/11 12:32 AM, MFPA wrote:
On Sunday 13 March 2011 at 5:48:55 AM, in
mid:4d7c5ac7.70...@adversary.org, Ben McGinnes wrote:
I'm assuming a short descriptive paragraph in the gpg.man file plus
some good info becoming available over time in various start up
guides etc. by searching
On 14/03/11 1:12 AM, MFPA wrote:
On Sunday 13 March 2011 at 7:58:36 AM, in
mid:4d7c792c.2000...@adversary.org, Ben McGinnes wrote:
So, my question, how would you enable a user to display those keys
with known names or identities without searching for a specific key
belonging to a particular
On 14/03/11 5:19 AM, Ingo Klöcker wrote:
On Sunday 13 March 2011, Ben McGinnes wrote:
On 13/03/11 7:24 AM, MFPA wrote:
Or simply use pgp-inline so that the disclaimer comes after the
signature.
Yes, this is a fine example of why in-line still has a place in the
world.
I disagree
On 14/03/11 11:44 AM, MFPA wrote:
On Sunday 13 March 2011 at 5:02:52 PM, in
mid:4d7cf8bc.3060...@adversary.org, Ben McGinnes wrote:
I'd hardly call it flashing lights just to be listed on the
keyserver, especially when the same data source also contains a
large amount of effectively useless
On 16/03/11 7:16 AM, Robert J. Hansen wrote:
On 3/15/11 3:53 PM, Ben McGinnes wrote:
It's simple, data which may have been encrypted 15+ years ago may
still have value to the people who encrypted it, even if they have
since chosen to move from older programs (e.g. PGP 2.x
On 16/03/11 9:54 AM, MFPA wrote:
On Monday 14 March 2011 at 1:06:26 AM, in
mid:4d7d6a12@adversary.org, Ben McGinnes wrote:
Anyway, out of curiosity, did you ever receive spam by that address
and prove it had been harvested from the keyservers? I still think
harvesting addresses from
On 16/03/11 2:04 PM, Doug Barton wrote:
I do, occasionally, get spam directed to addresses that I am sure
were harvested from they keyservers.
How long ago would those addresses have been harvested from the
keyservers?
However at the far outside of the range it's no more than 10/month,
On 16/03/11 10:42 AM, David Shaw wrote:
GnuPG does the MDC by default whenever all the keys can handle it
(or if the chosen cipher is 256 bits)
Is that 256 bits only or 256 bits and larger?
Regards,
Ben
signature.asc
Description: OpenPGP digital signature
On 16/03/11 2:37 PM, Robert J. Hansen wrote:
On 3/15/2011 11:28 PM, Ben McGinnes wrote:
Is that 256 bits only or 256 bits and larger?
Given there are no symmetric ciphers in OpenPGP that use more than a
256-bit key, I think the answer here is yes. :)
Heh. For some reason my brain
On 16/03/11 8:50 PM, Werner Koch wrote:
On Wed, 16 Mar 2011 06:33, b...@adversary.org said:
Okay, so that would cover 3DES too? Surely there can't be many
No. DES and thus 3DES have a blocksize of 64 bit. The blocksize is not
related to the keysize.
Ah, right, got it. Thanks.
On 21/03/11 5:11 AM, Jonathan Ely wrote:
The attached .asc file causes problems? I have disabled that but
still enabled the header. Why would the .asc attachment option be
there if it causes problems?
The .asc file is the GPG signature and does not cause problems. The
signature that is
On 21/03/11 6:11 AM, Jonathan Ely wrote:
Firstly, what is MUA? I hear that but am not sure what that means.
MUA = Mail User Agent, e.g. Thunderbird, Outlook, Apple Mail, etc.
MTA = Mail Transfer Agent, e.g. Sendmail, Postfix, Exchange, etc.
Secondly, I have disabled that in Thunderbird. I had
a message or reply to one (but not when I forward a
message).
Regards,
Ben
--
Ben McGinnes http://www.adversary.org/ Twitter: benmcginnes
Systems Administrator, Writer, ICT Consultant
Encrypted email preferred - primary OpenPGP/GPG key: 0xA04AE313
http://pgp.mit.edu:11371/pks/lookup?op
On 21/03/11 8:16 AM, Jonathan Ely wrote:
Really? For me, it is much easier to access the newest reply instead of
using the Down Arrow key to find it. Gmail always worked the same way
for me.
It does make it easier to follow a conversation in context if multiple
sections of a conversation are
On 18/04/11 11:49 AM, Jonathan Ely wrote:
Version 1.4.11 is still the latest of that branch, right? That is
what the download page says but some times there are later versions
than what is reported. Media Player Classic is a good example of
this.
Yes, 1.4.11 is still the latest. Werner is
On 19/04/11 1:15 PM, Robert J. Hansen wrote:
Megacorporations will probably not be willing to drop that kind of
coin on dedicated key crackers, but if bin Laden's current GPS
coordinates were protected by RC5/64 you'd see Fort Meade's chip fab
line working round-the-clock shifts.
Actually
On 27/04/11 7:04 PM, Aaron Toponce wrote:
On Sun, Apr 17, 2011 at 03:49:58PM -0700, Doug Barton wrote:
Summary: A 3-word password (e.g., quick brown fox) is secure against
cracking attempts for 2,537 years.
http://www.baekdal.com/tips/password-security-usability
I'm just going to drop this
On 13/06/11 9:16 AM, Jerome Baum wrote:
Who makes these considerations?
In any case, what kind of database is this that it's too much of a
hassle to copy over? What size, etc.?
Given this line from the original post, developers for the Arch Linux
distribution need a way to sign databases
On 20/06/11 4:32 AM, Jerome Baum wrote:
That's actually quite common for software to do. There are a few
notable exceptions (sort(1) comes to mind), but it's not something you
normally have to worry about. People tend to append .gpg anyway. :)
Actually people tend to ignore the -o flag and
On 22/07/11 12:20 AM, Aaron Toponce wrote:
On Wed, Jul 20, 2011 at 06:01:23PM -0600, Jay Litwyn wrote:
-BEGIN PGP MESSAGE-
Version: GnuPG v2.0.17 (MingW32)
Comment: http://ecn.ab.ca/~brewhaha/gpg/Keyprint_Biometric.mp3.pgp
On 23/08/11 12:39 AM, Mike Acker wrote:
some of us use more than one email address. with GPG it is simple to
add a secondary ID to a key and this seems to work quite well.
when a change like this is made it is desirable to update the
keyserver. what happens when you re-upload a key to the
On 26/08/11 3:37 AM, Werner Koch wrote:
On Thu, 25 Aug 2011 17:22, la...@thehaverkamps.net said:
changing from 4096 to 8192 bit)
DON'T.
I understand the reasons for this, but is there any reason for not
using an 8kb (or larger) master/certification key with more normal
subkeys (e.g. a
1 - 100 of 218 matches
Mail list logo
