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 sign
> 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 (inc
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 to
> 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
__
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
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 i
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 it
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 se
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 visu
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 a
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 arc
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 appropriat
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
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 I
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 keys;
> > - encrypt data
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 encryp
-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 so that it's guaranteed that
> Alice is not Eve.
Ass
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 so that it's guaranteed that
> > Alice is not Eve.
>
> On 7 Jun 2017, at 06:55, Stefan Claas wrote:
>
> The procedure went like this: I inserted my id-card in a certified
> card reader, which i purchased, startet the german certified id-card
> software "AusweisApp2" to connect to the CA Server and the server
> checked my id-card online and after v
19 matches
Mail list logo
