Andrew Gallagher wrote:
> The only way that a company would end up archiving a password reset
> email encrypted to an ADK would be if an employee was using their work
> email address for password resets. If using their work email for this
> purpose is inadvisable, then it is
On 2 May 2023, at 02:18, Michael Richardson wrote:
>
> It's the initial investigation of an irregularity where there could be a
> problem.
These examples are becoming increasingly contrived. If you are investigating
fraud by someone who can read all your company emails, don’t discuss it over
On Sun, 30 Apr 2023 13:58, Andrew Gallagher said:
> The danger of an “ignore ADK” option is that it gives a false sense of
And not to forget the other important use case: Add an ADK for your own
second device so that you are able to decrypt also on that device -
without the need to keep the
Michael Richardson wrote:
Jacob Bachmeyer wrote:
>> I'm unclear if this is a new feature (I think so), and if so what
happens if
>> the sender hasn't upgraded yet?
>>
> My understanding: ADKs are new and do not work without support on the
> sender's side. The ADK is a
Jacob Bachmeyer wrote:
>> I'm unclear if this is a new feature (I think so), and if so what
happens if
>> the sender hasn't upgraded yet?
>>
> My understanding: ADKs are new and do not work without support on the
> sender's side. The ADK is a request to also encrypt any
On 1 May 2023, at 12:40, Ineiev via Gnupg-users wrote:
> now, I generate a key
> for y...@guan.edu locally and add 0123456789ABCDEF as an ADK (BTW,
> will GnuPG complain if the only encryption-capable subkey is ADK?
Or you could just use an alias…?
A
On Sun, Apr 30, 2023 at 10:52:10PM -0500, Jacob Bachmeyer via Gnupg-users wrote:
>
> That is an almost prototypical example. In that case, the "archive" key
> would actually be the main subkey, and the list recipients' personal keys
> would be attached as ADKs.
>
> Another example: suppose I
Hi Johan,
Johan Wevers via Gnupg-users wrote:
>On 2023-04-30 21:01, Ineiev via Gnupg-users wrote:
>
>>> All I want is an option to ignore adk's - and it should not claim
>>> anything else than that.
>>
>> Can't you remove ADK subkeys from your keyring?
>
>On someone else's key?
>
Yes.
1.
Michael Richardson wrote:
Jacob Bachmeyer via Gnupg-users wrote:
> ADKs seem particularly valuable to me as a solution to the "group inbox"
> problem that avoids actually sharing private key material: simply
> attach encryption subkeys for all recipients to the "group inbox"
>
Jacob Bachmeyer via Gnupg-users wrote:
> ADKs seem particularly valuable to me as a solution to the "group inbox"
> problem that avoids actually sharing private key material: simply
> attach encryption subkeys for all recipients to the "group inbox"
> certificate. This requires
Johan Wevers via Gnupg-users wrote:
On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote:
[...]
The danger of an “ignore ADK” option is that it gives a false sense of
security. It is already possible for an employer to require escrow of the
decryption subkeys of their employees -
There are 2 simple workarounds to employment ADK's :
[ 1 ]. Send a symmetrically encrypted message to the key with the
ADK(This will require an agreed upon symmetric passphrase communicated
in person, phone, or another non-ADK manner)
[ 2 ]. Generate a non-ADK key, not uploaded to any server
On 2023-04-30 21:01, Ineiev via Gnupg-users wrote:
>> All I want is an option to ignore adk's - and it should not claim
>> anything else than that.
>
> Can't you remove ADK subkeys from your keyring?
On someone else's key?
--
ir. J.C.A. Wevers
PGP/GPG public keys at
On Sun, Apr 30, 2023 at 05:41:31PM +0200, Johan Wevers via Gnupg-users wrote:
>
> All I want is an option to ignore adk's - and it should not claim
> anything else than that.
Can't you remove ADK subkeys from your keyring?
signature.asc
Description: PGP signature
On 2023-04-30 16:54, Andrew Gallagher via Gnupg-users wrote:
>> That might be, but it is nowhere certain that this escrow will happen,
>> especially if they roll out adk's.
>
> You’re inverting the burden of proof here. The important consideration is
> that E2E can’t prove that a key *wasn’t*
On 30 Apr 2023, at 14:42, Johan Wevers via Gnupg-users
wrote:
>
> On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote:
>> Whether this is done voluntarily or under duress from their employer is an
>> opsec issue, not a comsec one.
>
> If it is an ex-employer that might be more
On 2023-04-30 14:58, Andrew Gallagher via Gnupg-users wrote:
> E2E encryption can’t protect you from your correspondent disclosing your
> communication at the other end.
That is obvious.
> Whether this is done voluntarily or under duress from their employer is an
> opsec issue, not a comsec
On 30 Apr 2023, at 13:45, Johan Wevers via Gnupg-users
wrote:
>
> On 2023-04-30 14:10, Werner Koch via Gnupg-users wrote:
>
>> It does not make any sense so have such an option. If a user wants to
>> allow colleagues or an archive system to decrypt her mails that is her
>> decision.
>
>
On 2023-04-30 14:10, Werner Koch via Gnupg-users wrote:
> It does not make any sense so have such an option. If a user wants to
> allow colleagues or an archive system to decrypt her mails that is her
> decision.
What I've had in practice in one company: you got a company key with a
personal
On 2023-04-30 13:22, Andrew Gallagher via Gnupg-users wrote:
> Just curious, what’s the threat scenario here?
The HR department of the receiver.
--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html
___
Gnupg-users
On Fri, 28 Apr 2023 16:57, Johan Wevers said:
> So you finally caved in to the backdoor demands.
In business it is quite common to share subkeys with others. Thus the
ADSK makes it only more explicit and flexible. See the blog entry.
> What I'm missing (maybe I just didn't found it?) is an
On 30 Apr 2023, at 11:30, Johan Wevers via Gnupg-users
wrote:
>
> On 2023-04-30 1:15, ckeader via Gnupg-users wrote:
>
>> Can't call it that as long as it's under user control (every long option of
>> the software has an equivalent config file option. You don't add such a key
>> via config
On 2023-04-30 1:15, ckeader via Gnupg-users wrote:
> Can't call it that as long as it's under user control (every long option of
> the software has an equivalent config file option. You don't add such a key
> via config or command line, no adsk will happen as it's not configured).
On my key,
Johan Wevers via Gnupg-users writes:
> On 2023-04-28 15:47, Werner Koch via Gnupg-users wrote:
>
> > * gpg: New command --quick-add-adsk and other ADSK features.
> > [T6395, https://gnupg.org/blog/20230321-adsk.html]
>
> So you finally caved in to the backdoor demands.
>
> What I'm
gnupg-users@gnupg.org wrote in
<20230428230349.429d3d3a@localhost>:
|Johan Wevers via Gnupg-users wrote:
|>On 2023-04-28 15:47, Werner Koch via Gnupg-users wrote:
|>
|>> * gpg: New command --quick-add-adsk and other ADSK features.
|>> [T6395, https://gnupg.org/blog/20230321-adsk.html]
Hi Johan,
Johan Wevers via Gnupg-users wrote:
>On 2023-04-28 15:47, Werner Koch via Gnupg-users wrote:
>
>> * gpg: New command --quick-add-adsk and other ADSK features.
>> [T6395, https://gnupg.org/blog/20230321-adsk.html]
>
>So you finally caved in to the backdoor demands.
If there is
26 matches
Mail list logo
