Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

On 07.06.17 00:04, MFPA wrote: > > > On Tuesday 6 June 2017 at 5:07:18 PM, in > , Stefan Claas > wrote:- > > > > Therefore qualified CA's > > in my opinion are mandatory where each user in each > > country [may] register > > with his/her id-card

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tuesday 6 June 2017 at 5:07:18 PM, in , Stefan Claas wrote:- > Therefore qualified CA's > in my opinion are mandatory where each user in each > country [may] register > with his/her id-card

Re: Key management for archives

Il 06/06/2017 22:40, Konstantin Gribov ha scritto: > In first scheme DEK is never stored in plain text. It used while > encrypting archive and encrypted with gpg (or any other cryptographic > means) and plain text version is removed right after that. There's a big misunderstanding here: the

Re: Key management for archives

On Tue, Jun 6, 2017 at 11:03 PM NdK wrote: > Il 06/06/2017 20:13, Konstantin Gribov ha scritto: > > > I can think of more simpler approach: > > - generate secure random for symmetrical data encryption key (DEK); > > - encrypt that key for authorized users on their public

Re: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

On 06.06.17 20:46, Charlie Jonas wrote: > On 2017-06-06 19:12, Stefan Claas wrote: >> I tried also with Enigmail under OS X but when checking the signatures here >> from the list members i always get the blue "Untrusted Good Signature". > Yes I get this as well. Interestingly whatever trust level

Re: Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

On 2017-06-06 19:12, Stefan Claas wrote: > I tried also with Enigmail under OS X but when checking the signatures here > from the list members i always get the blue "Untrusted Good Signature". Yes I get this as well. Interestingly whatever trust level I give keys, Enigmail on OSX seems to want to

Re: Key management for archives

Il 06/06/2017 20:13, Konstantin Gribov ha scritto: > I can think of more simpler approach: > - generate secure random for symmetrical data encryption key (DEK); > - encrypt that key for authorized users on their public keys; > - encrypt data itself with something like ChaCha20 or AES in

Re: Key management for archives

Diego, I can think of more simpler approach: - generate secure random for symmetrical data encryption key (DEK); - encrypt that key for authorized users on their public keys; - encrypt data itself with something like ChaCha20 or AES in appropriate mode. In such case you could give end user an

Fwd: Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

On 06.06.17 12:46, Peter Lebbing wrote: > On 06/06/17 05:30, Duane Whitty wrote: >> As I understand the concept of TOFU (Trust On First Use), when you >> receive a signed email gpg tests that signature against the key >> retrieved from the public key servers associated with the email. > TOFU is

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

On 06.06.17 18:07, Stefan Claas wrote: > On 06.06.17 04:11, Daniel Kahn Gillmor wrote: >> On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote: >>> On 05.06.17 22:26, Daniel Kahn Gillmor wrote: what does "bullet-proof" mean, specifically? >>> For me it means that the idendicons should be

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

On 06.06.17 04:11, Daniel Kahn Gillmor wrote: > On Tue 2017-06-06 01:24:43 +0200, Stefan Claas wrote: >> On 05.06.17 22:26, Daniel Kahn Gillmor wrote: >>> what does "bullet-proof" mean, specifically? >> For me it means that the idendicons should be visually easy to read >> and cryptographically

Re: Certification-only key

On 2017/06/06 14:38, Peter Lebbing wrote: > However, if somebody has used a timestamping service to prove the > signature was in fact really issued before the key expired, you'll have > to claim that you had already disclosed the secret key back then. Even > though you didn't. So you can't prove

Re: Certification-only key

On 06/06/17 15:14, Andrew Gallagher wrote: > To protect against this, one would use a timestamping service to sign > the secret key publication, thereby proving the publication was earlier > than the forgery. I think you're going backwards about this. This is how I understand it: Until the key

Key management for archives

Hello all. I'd need to handle an archive with many big files (~200GB each). The system receives "plain" files in a "dropbox" folder, then encrypts 'em to a (set of) public key(s) (no corresponding private keys on this system) and deletes source files. Up to this point it should be OK (a cronnable

Re: scute / firefox: cannot connect to GPG agent

> You may also try the patch below. > [...] > * src/agent.c (scute_agent_get_cert): Reject card certificate if > it does not start with an ASN.1 sequence tag. The batch works for me using Yubikey 4. Thanks, Fabian signature.asc Description: PGP signature

Re: Certification-only key

On 2017/06/02 18:25, Peter Lebbing wrote: > I did later realize that if somebody used a timestamping service to > timestamp a document you signed, you would have to argue that you > already published your secret key before that time. To protect against this, one would use a timestamping service

Re: scute / firefox: cannot connect to GPG agent

> I'll try to find a way to erase the certificate from the Yubikey. You may also try the patch below. It should allow Scute to ignore the data read from the token if it does not look like a proper DER-encoded certificate. It's not a fool-proof check, but it should already catch a lot of cases

Re: Fwd: Re: Question for app developers, like Enigmail etc. - Identicons

On 06/06/17 05:30, Duane Whitty wrote: > As I understand the concept of TOFU (Trust On First Use), when you > receive a signed email gpg tests that signature against the key > retrieved from the public key servers associated with the email. TOFU is about *consistency*. It says: this e-mail is