Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 02/18/2018 05:55 PM, Ben McGinnes wrote:
> So you took a system built from the outset on a security model founded
> entirely on public key exchanges between distributed and federated
> (both self-determining and self-governing) nodes ... and then spent a
> considerable amount of time and effort making that system centralised
> in order to meet certain types of common business use cases ...
>
> ... with a software package which ships with a complete implementation
> of S/MIME as well ...
No, there is no S/MIME implementation because the PKI model it relies on
is inherently precarious for enterprise usage because of using
third-party certificates. Once a 3rd party CA is trusted, all users it
certified becomes trusted while those users have no business
relationship with the enterprise.

> Hmm ...
>
> Okay, I just have one question:
>
> *Why?!*
The short answer is that neither S/MIME's PKI or OpenPGP's web-of-trust
is suitable for organizational uses in term of defining trusted people
for the organization. In addition, current clients of both require
considerable efforts at the end-user side to configure and use. For a
longer analysis, here is a white paper:
https://www.cs.utah.edu/~luzhao/pub/doc/autonomous-certificate-authority.pdf


Thanks,
Lou

>
>
> Regards,
> Ben


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/05/2018 12:54 PM, Kristian Fiskerstrand wrote:
> On 01/05/2018 05:29 PM, Lou Wynn wrote:
>> The auditing key is certified by the root key and stays with the latter
>> in my design. Only the administrator can make policy to turn on/off
>> auditing, the client plugin takes corresponding actions automatically.
>> End users don't need to do anything, namely, using or not using the
>> auditing key to encrypt is completely transparent to end users. As a
>> result, there is no such issue of "forgetting to add it."
> Can you please elaborate on how this would be compatible with existing
> implementations of RFC4880?
>
>
If you asked about the auditing key compatibility, then it is probably
not the right question because RFC4880 does not talk about it at all. My
client plugin takes automatic action to encrypt a message with two keys
and sends to one receiver, which I don't think violates the RFC.

However, there is a potentially issue related to compatibility for the
system as a whole depending on the direction. For example, if you import
your current PGP key into my system, then you can still use the key
without a problem because as a part of the importing process the server
adds a new certificate with necessary properties made by the certifying
key. The client plugin of my system will recognize your key as valid
once you have this certificate.

In the other direction, if you export a key from my system and want to
use it in your current PGP client, you can do so because a key in my
system is still a valid PGP key. However, you don't have any benefits of
my system such as trust realm/group support because your current PGP
client does not enforce the autonomous certification authority model.

Thanks,
Lou



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> It seems to me, though, that the idea was to provide a means for the
> company to repudiate an employee's key even if the employee was no
> longer available.

This is just one of the benefits enabled by my goals which I stated at
the beginning, and it is most related to central management of keys.
There are systems that have attempted to solve one or two of them with
the cost of sacrificing others. My take is doing them all with the new
trust model and its supporting mechanisms.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/05/2018 01:10 AM, Kristian Fiskerstrand wrote:
> There are easily scenarios where a customer forgets to add the "auditing
> key", making the data unavailable to the organization, in particular in
> context of loss of employee.
>
The auditing key is certified by the root key and stays with the latter
in my design. Only the administrator can make policy to turn on/off
auditing, the client plugin takes corresponding actions automatically.
End users don't need to do anything, namely, using or not using the
auditing key to encrypt is completely transparent to end users. As a
result, there is no such issue of "forgetting to add it."

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/05/2018 12:18 AM, Kristian Fiskerstrand wrote:
> Businesses have reasonable need to access their data, so they need to
> have access to his private keys, which contradicts "which
> is meant to prevent others from using his private keys", although
> reading it again I presume you're limiting the statement to
> non-authorized personnel in the normal scenario?

This reason is vague and invalid. The purpose of a private key is
two-fold: encryption and message authorization. The only need for an
organization to access their data is decrypting the encrypted data,
which is satisfied by the auditing key. I don't see any valid reason to
damage message authorization. I'd suggest you read Ben McGinnes's post.

If you still insist that there is value in accessing employees' private
key, then I would say that you belong to the type of organizations that
*want* to access employee's private keys although doing so causes more
damages. I described the two categories of organizations when replying
Ben's post.

This is another reason that I want to modernize PGP for organizations
because when people use PGP in such an environment they tend to make
dangerous decisions such as key escrow or encryption gateway to meet
organizational management requirements while compromising message
authorization.

Thanks,
Lou



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 04:15 PM, Kristian Fiskerstrand wrote:
> On 01/05/2018 01:12 AM, Lou Wynn wrote:
>> I guess that you've missed somewhere I said in my previous posts that
>> the end user chooses his own password to protect his key password, which
>> is meant to prevent others from using his private keys.
> At which point I'm wondering about your priorities, if the corporation
> doesn't have access to the data (without the specific encryption key
> being included) what is the value?
Sorry, I don't get it. Can you explain your question again? What data,
in which scenario?

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 04:31 PM, Lou Wynn wrote:
> I think that I simplified my original description too much. The two
> levels of protection works like this.
> 1. The employee chooses his own password, which is used to encrypt his
> private key.
>
> 2. Then the encrypted key is encrypted with the guard key.
>
> When a client plugin passes authentication, the sever decrypts from 2's
> result and sends it to the client.
I'm sorry for missing another step in sending a key to the client. After
the server decrypts the encrypted key material with the guard key, it
uses the public key of the client plugin to encrypt it and sends it to
the client. The client plugin decrypts it first with the plugin key, and
then the user's own password is required to decrypt the private key.

The guard key and the plugin key here are used to defy the
man-in-the-middle in either direction and provide secure channels.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 02:28 PM, Ben McGinnes wrote:
> On Wed, Jan 03, 2018 at 05:34:30PM -0800, Lou Wynn wrote:
>> The management of users' private key is a little more complicated. I
>> use two levels of protection. One level is at the organization. An
>> organization actually has a fourth key, which I call the guard key,
>> to encrypt the password of user's private key. This guard key is
>> also managed by the key management system. In addition, a user can
>> choose another her own password to encrypt the key password too.
> That just spreads the potential points of human failure and you run
> the risk that anyone with access to this guard key would be able to
> abuse the position to access an employee's credentials (saying they
> don't have access to the private key doesn't hold any weight on a
> company intranet where they've probably already got root/admin
> access).  So it'd be too easy for some unscrupulous sys admin (you
> might trust you, but what happens when you leave, do you know your
> successor?) has a personal issue with someone in, say, marketing and
> stitches them up with a few choice forged and signed emails.
>
> No, that's a *bad* plan and creates all sorts of horrible legal
> problems for the company or at least has the very real potential to do
> so.

I think that I simplified my original description too much. The two
levels of protection works like this.

1. The employee chooses his own password, which is used to encrypt his
private key.

2. Then the encrypted key is encrypted with the guard key.

When a client plugin passes authentication, the sever decrypts from 2's
result and sends it to the client. This key material is still encrypted
by the employee's own password. The decryption of 1 happens at the
client plugin.

My estimates is that there exist different types of organizations. Some
want to access employee's key, and some don't. So For the former, they
can choose to skip the first level of protection. For the latter, they
can require to use it. An organization can only change from using the
second protection only to using both, but not the other way around.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 04:06 PM, Kristian Fiskerstrand wrote:
> But in the end it doesn't matter, as the organization anyways has access
> to the private key material of the employee. So a third party "auditing
> key" is irrespective of any access goals.
>
I guess that you've missed somewhere I said in my previous posts that
the end user chooses his own password to protect his key password, which
is meant to prevent others from using his private keys.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 02:57 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 11:24 PM, Lou Wynn wrote:
> but you add the requirement that all end users sending email to you
> require to validate the auditing key as well (auditing is likely wrong
> word, archiving is more likely relevant). for auditing you certainly
> want gpg-agent monitoring of assuan channel in separate domain.
I don't get the exact meaning of this paragraph.

I'll try to explain a little. If the administrator sets up the auditing
policy (which implies that the auditing is an option), then the plugins
of employees will also use the auditing key to encrypt a message besides
receiver's public key. This is a little different from what I said
earlier about users' plugins because this is a design decision which has
not been finalized: whether to make employees or employees plus partners
to use the auditing key. This might become an option too.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 02:59 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 11:14 PM, Lou Wynn wrote:
>> Compared to using two CAs, my design introduces two properties to a
>> certificate. One is the certificate type, which is "p" for a partner and
>> "e" for an employee.
> why not make it compatible with rfc4880 directly? your proposal would
> require client handling of e.g notation data?
This is exactly the reason for my modernizing web of trust. I cannot
find a way to make it compatible with rfc4880 and meet all my goals. I'd
love to hear your alternatives if it is possible. For example, I'd like
to deprecate how trust is assigned values and used in the rfc. However,
I'd love to use existing good mechanisms as many as possible, such as
the entire PGP data format.

As for changes to PGP, I do require new certificate properties and
certificate validations to enforce trust realms and groups.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 02:08 PM, Kristian Fiskerstrand wrote:
> no, there isn't necessarily a client plugin, the gateway decrypts the
> message before it hits the internal email server, so end-user sees
> un-encrypted message, this is protecting transport, but security of
> on-site is ensures through different channels
I see. The gateway solution is contradictory to my end-to-end email
security goal, which requires that only the end user can use his own
private key. The gateway is a total disaster if the gateway is breached.
> I don't see this as disagreeing, this means you don't have any benefit
> from storing the email in encrypted form once it hits the corporate
> network, so you're better off decryption it at gateway anyways.
>
I guess that you missed the auditing key part. I introduced it to meet
auditing requirements or scanning of messages without using end user's
private keys.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 02:04 PM, Kristian Fiskerstrand wrote:
>> I don't think it necessary to use business unit level certifying keys in
>> my design. It introduces management overhead which shadows its benefits.
>> If you understand the concept of trust realm/trust group and its
>> verification methods I described before, then there is no need for a key
>> hierarchy at all. Can you describe a use case that demands the use of
>> unit level certifying key? I'll try to explain how to implement it with
>> trust realm and groups.
> I didn't necessarily say businsess unit level CA, but separation between
> employee and business partner CAs.
Compared to using two CAs, my design introduces two properties to a
certificate. One is the certificate type, which is "p" for a partner and
"e" for an employee. The other property is the trust group, which is a
list of groups and tells the certificate verifier the groups that the
key belongs to. These two properties are implemented as notations of the
certificate.

Thanks,
Lou




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 01:04 PM, Ben McGinnes wrote:
> On Thu, Jan 04, 2018 at 12:40:59AM +, MFPA wrote:
>> For example, my ISP [0] says "All staff keys are signed using the
>> company signing key. This is very much like a traditional company
>> seal. Only the director has access to this key and it is only used
>> for signing other keys. If/when a member of staff leaves a
>> revocation is issued of that signature and loaded on to keyservers."
>>
>> [0] 
> Cute, but they're fast approaching the point where anyone with a
> decent beowolf cluster and an axe to grind could mess with that 1K
> certification key they're using there.

Can you explain what the problem is? I don't really know what you mean,
but I've love to hear.

Thanks,
Lou



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 01:31 PM, Kristian Fiskerstrand wrote:
> On 01/04/2018 10:21 PM, Lou Wynn wrote:
>> After a client plugin logs in successfully, the server sends the user's
>> encrypted email key to the client.
> Aren't you better off with a gateway solution like PGP Universal /
> Symantec Encryption Server (or for that matter if GPGRelay is still
> alive) ? That never exposes key material to client, i.e always operates
> within corporate infrastructure and removes a lot of complexity and
> allows for easier indexing/searching.
>
It's doable, but I'd like to make sure that I understand what you mean
by "within corporate infrastructure?" Do you mean the client plugin
sends requests to the server to decrypt and verify received messages?
This is definitely a trade-off between key security and performance. But
I don't see any obvious benefits given that the user's computer that
runs the client plugin also belongs to corporate infrastructure. If the
user's computer is compromised, then the administrator simply clean up
the computer and re-install or re-initialize user's email client, which
includes the client plugin.

In my design, each end user does not have a permanent identity like in
OpenPGP where he needs to accumulate his reputation for
"trustworthiness." The only authority is the organization's root key.
Among other things, a user's key is simply a way of declaring that the
email message is authorized by the user who has been certified by the
organization's root key. In this situation, a user's key is not more
important than his email account.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/04/2018 12:25 AM, Andrew Gallagher wrote:
>> On 4 Jan 2018, at 04:42, Lou Wynn <lewis...@gmail.com> wrote:
>>
>> It has a client key and uses it to log into the server, which is
>> similar to SSH key authentication, to retrieve the private key after
>> authentication.
> This bit confuses me. If you already store a private key locally, why use it 
> to download a second private key? If you’re using a key escrow system then 
> surely you just need to upload the private key once and keep a local copy?
>
> A
There is no key escrow in my design because a user's private key should
not be accessible to anyone else including the administrator. For an
organization, granting the administrator too much, unnecessary privilege
is dangerous especially when he leaves.

Let me try to explain it in another way. Each end user has an email key.
When she uses multiple email clients, each client plugin has a key pair
serving as the identity of the client plugin. The client plugin
registers itself on the server with its public key when the client
plugin is installed or initialized. This key belongs to the plugin and
is used for the plugin to log into the server. The administrator and/or
the end user can monitor how many client plugins the user uses. The
administrator may disable the login of a particular client plugin if it
is compromised such as an employee loses his computer.

In addition, the administrator may optionally set up a policy that
requires the user to choose a login password except for the public-key
authentication of the client plugin.

After a client plugin logs in successfully, the server sends the user's
encrypted email key to the client.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/03/2018 04:40 PM, MFPA wrote:
>> It is already the case that an organisation does not need to depend on
>> third-party CAs to certify its staff's OpenPGP keys.
>>

It's true for OpenPGP because OpenPGP is a distributed system, there is
no single CA, or it doesn't have the concept of CA at all. My original
implicit reference is PKI based S/MIME.

The autonomous certificate authority model is different from both PKI
and web of trust. As I explained in one of my previous posts that this
model clearly defines what trustworthiness is. The short version is:

A trusted key or trustworthiness means that the sender's certificate is
verified to be in the same trust realm or in the same trust group with
the receiver, besides traditional signature verification.

In this model, end users are freed from managing trust relationship
completely because the trustworthiness can be checked mechanically and
it makes sense to organizational usages.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/03/2018 05:34 PM, Lou Wynn wrote:
>> Are you talking about something like a shared keyring? Or just　managing 
>> trust relationships by issuing key certifications and
>> revocations?
> The short answer is for both. End users do not need to manage their

When I said for "both," I might have misunderstood what you meant by a
shared keyring? Can you explain it a little bit? My system doesn't share
anything that is related to user private keys, except for that encrypted
private keys are saved in a database. An analogy is placing two people's
encrypted PGP secret keyring on a file server, and decryption is still
done at the client side. I'm not sure if this is what you meant by a
shared keyring.

Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

I just realized that I overloaded the meaning of signature verification.
Here, signature verification, both in my previous discussion and in the
receiver's UI, also includes the certificate verification described in
2.b, in addition to traditional signature verification.

Thanks,
Lou

On 01/03/2018 01:04 PM, Lou Wynn wrote:
> Yes, "trusted" keys do not mean much without contexts. There are few
> contexts to see what trustworthiness means.
>
> 1. From certificate verification point of view, a trusted key means that
> the certificate is verified to be in the same trust realm or in the same
> trust group with the receiver.
>
> 2. From the user interface point of view, a trusted key is reflected by
> marking the sender's signature is verified, and an untrusted key is
> marked by the warning that the signature cannot be verified. An
> automated or manual process can be applied to delete or quarantine
> messages whose signature verification fails. The screenshots on the web
> link show this intuitive UI. Of course, the final decision about what to
> do with such messages is up to the receiver. The warning of signature
> verification makes the receiver aware of the sender status, which is
> either certified to be in the same trust realm/group or not being
> certified as such.
>
> Thanks,
> Lou
>
>

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Modernizing Web-of-trust for Organizations

[Lou Wynn]

On 01/03/2018 11:21 AM, Daniel Kahn Gillmor wrote:
> Hi Lou--
>
> On Tue 2018-01-02 23:02:08 -0800, Lou Wynn wrote:
>> b. Its employees and business partners do not manually manage their own
>> keys and trust relationship, and the administrator centrally manages all
>> certificates and trustworthiness for the organization.
> backing up a bit here -- what kind of "trustworthiness" are you talking
> about in your proposal?  your description includes several uses of the
> word "trust", but no clear explanation of what that trust entails.
>
> saying that keys are "trusted" doesn't mean much on its own.  What is a
> "trusted" key allowed to do that an "untrusted" key is not allowed to
> do?
>
> --dkg

Yes, "trusted" keys do not mean much without contexts. There are few
contexts to see what trustworthiness means.

1. From certificate verification point of view, a trusted key means that
the certificate is verified to be in the same trust realm or in the same
trust group with the receiver.

2. From the user interface point of view, a trusted key is reflected by
marking the sender's signature is verified, and an untrusted key is
marked by the warning that the signature cannot be verified. An
automated or manual process can be applied to delete or quarantine
messages whose signature verification fails. The screenshots on the web
link show this intuitive UI. Of course, the final decision about what to
do with such messages is up to the receiver. The warning of signature
verification makes the receiver aware of the sender status, which is
either certified to be in the same trust realm/group or not being
certified as such.

Thanks,
Lou



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: SHA1 depreciation ??

[Lou Wynn]

On 06/29/2017 02:31 PM, Robert J. Hansen wrote:
>> SHA1 got broken some months ago, but I see no useful move to get rid
>> of using it for even new stuff.
> (a) Not for OpenPGP's uses.  For our uses it's still safe, although we
> recommend moving to other, better, hashes as soon as possible.
>
> (b) It's pretty easy to avoid using SHA-1.  There are still a small
> number of places where it's mandatory, and this will not change until
> the IETF OpenPGP Working Group publishes the v5 key specification.
>
> (c) The IETF OpenPGP WG is working on a new key specification ("v5")
> which completely gets rid of SHA-1.

As for the current version v4, SHA1 is used to compute the fingerprint.
Are there other mandatory places?

Others such as signature hash and password hash do not depend on SHA1.

Do you know any time frame and significant changes of v5 specs?


Thanks,

Lou

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Creating Unique Fingerprint

[Lou Wynn]

According to my understanding of crypto theory, your only way is to
generate keys and compare their fingerprints and with the value you
want. I would be surprised that you can find one in your lifetime. Or
it'd be a breakthrough in cryptography if you managed to do it somehow.

Thanks,
Lou

On 06/18/2017 07:23 PM, Long Si wrote:
> Hi
>
> I am on Linux, and would like to generate a key with "unique 40" fingerprint.
>
> eg 1: Starts with ABCD  ... 
>
> eg 2: Starts with AXXX  ... XXXA ends with A
>
> eg 3:  ...  without any '0' character at all
>
> How would I go about writing such a script? Don't mind running for
> months to get these sets.
>
> Regards
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

exported subkey usage?

[Lou Wynn]

Hi,

I created a master key and two subkeys with one subkey being signing and
the other encryption. I then exported the two subkeys only.

However, when I used pgpdump to inspect packet types, both subkeys are
been marked as "RSA Encrypt or Sign (pub 1)." When I used another
program whose backend is BouncyCastle's PGP engine, the program cannot
tell which subkey is for what.

I deleted the key in my keyring and used GPG2 to import the two subkeys
back. To my surprise, they are correctly marked as [S] and [E].

What is going on here? Does GPG2 use some special way to mark the usage
of a subkey? How can I make it interchangeable with other programs?

I've attached the master key and the two subkeys to this letter so that
you can inspect them (I made up other info just for testing, so don't
worry about it). The OneMasterTwoSubkey has the master key with two
subkeys, and the other only has the subkeys. The passphrase is "1".


-- 
Thanks,
Lou



OneMasterTwoSubkey
Description: Binary data


TwoSubkeyOnly
Description: Binary data
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: export encryption (subkey) only?

[Lou Wynn]

On 01/03/2017 06:05 AM, Daniel Kahn Gillmor wrote:
> You should stick with a single public certificate per user (containing
> the two keys that you describe) so that your users' correspondents don't
> have to juggle multiple keys per person they communicate with.
>
>  --dkg

I overlooked this point, and it's important in the PGP world. One of my
goals is simplifying key management for organizational employees, and
it's nice to keep it interchangeable with people outside.

Thank everyone for helpful discussion.

-- 
Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Counterarguments Supporting GnuPG over Off The Record (OTR)

[Lou Wynn]

The author's stand is hilarious to me. He is

"My day-to-day work is in the field of information security and
especially incident handling, analysis and response. "

That's is to say, he's a security expert. But he compares himself with
Johnny by quoting "Why Johnny Can’t Encrypt”

Actually, there is a more recent paper called

"Why Johnny Still, Still Can’t Encrypt: Evaluating the Usability of a
Modern PGP Client"

https://arxiv.org/pdf/1510.08555.pdf

In my observation, what this type of papers point out is obvious:

It is non-trivial for non-technical people to make PGP work.



On 01/02/2017 06:41 PM, Christian Heinrich wrote:
> https://www.foo.be/2016/12/OpenPGP-really-works outlines a number of
> counter-arguments in support of GnuPG over OTR chat app and other
> alternatives.
>

-- 
Thanks,
Lou

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: export encryption (subkey) only?

[Lou Wynn]

On 01/02/2017 11:26 AM, Christopher Beck wrote:
>
> Hi Lynn,
>
>
> well, it is possible. There is an option for exporting only subkeys:
>
> gpg --output secret-subkeys --export-secret-subkeys SUBKEYID!
>
> It is important to use the exclamation mark at the end of the subkey-id!
>
> Instead of this: how about a company-key for trust-signing the
> exployees keys? Then, a custumor just hast to set the correct trust
> level to that company-key (okay, might be dangerous and not everybody
> wants to do this, but might be an option).
>


How about this: I use another company encryption key for auditing
purpose only. When employees send emails, they always use this
encryption key as well as the public keys of recipients for encryption.
This way, I don't have to backup employees' encryption keys, and can
even simplify to use a single key for each employee (this might be
arguable, but it's hard for me to convince myself that it's worthwhile
to use separate encryption key in this case). But I'm not sure if I need
to customize some PGP implementation in order to do so.

-- 
Thanks,
Lou

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

export encryption (subkey) only?

[Lou Wynn]

Hi,

I'm developing a key management solution for an organization. For an
employee, I'd like to generate two keys: one for signing and the other
for encryption. In my proposed solution, the encryption key should be
backed up in an organizational central server for auditing purpose, and
the signing key is only accessible to an user without being saved in
another location. This means that I have to separate the encryption key
from the signing key.

However,  the current GPG makes the signing key the master key and the
encryption the subkey. PGP standard seems not to allow transfer a single
subkey (RFC4880 Section 11) because it is always preceded by the master key.

I tried to export an encryption subkey only with GPG2, but importing the
subkey also lists the primary key. The man page of
--export-secret-subkeys reads:

   The second form of the command has the special property to render the
   secret  part  of  the primary key useless; this is a GNU extension to
   OpenPGP and other implementations can not be expected to successfully
   import  such a key.  Its intended use is to generated a full key with
   an additional signing subkey on a dedicated machine  and  then  using
   this  command  to  export the key without the primary key to the main
   machine.

It means that although the primary key is imported and listed, it is not
usable.

Has anyone have experience with this and been able to confirm it?

I'm also thinking about making two separate master keys, and doing so
seems to make me avoid the confusion of master-subkeys and make the
solution more portable in different implementations.

What's your opinion?

-- 
Thanks,
Lou


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Lou Wynn]

On 12/15/2016 04:18 PM, Andrew Gallagher wrote:
>> On 15 Dec 2016, at 19:24, Lou Wynn <lewis...@gmail.com> wrote:
>>
>> If the host machine is compromised, what's the purpose of doing encryption 
>> on the SmartCard? Attackers don't need to know the key to get your plaint 
>> ext, because it is on the host machine.
> The difference is that if you use a smart card in a compromised host, the 
> plaintext of particular messages may be compromised but the key itself 
> remains secure. It also helps in the case of hardware loss or theft, because 
> an encrypted drive can be brute forced, but smartcards have retry limits that 
> can't be worked around short of dissecting the silicon. 
I agree that a SmartCard can protect a private key, but that's a
marginal benefit because the bottom line of using a SmartCard is the
same as that of using an encrypted USB drive, which is

Do not use it in an untrusted or compromised host environment.

If you stick to the bottom line, then there is no point to emphasize the
difference.

The difference only comes in when you violate the bottom line and want
to use it in an untrusted or compromised host and "wish" that you could
get security. In this case, SmartCard can prevent your key from being
read. However, I would suggest anyone who uses a SmartCard not to do it
at all because using it in such an environment cannot give you security:
either signature or encryption.

I'd like to say more about "brute force" since you seem to misunderstand
the basic threat model of modern cryptography, whose design goal is only
to allow brute force attacks. However, it's computationally infeasible
in practice to guess the correct key by using brute force. A successful
cryptographic design is one where there is no systematic way to break it
unless an opponent can enumerate over the key space. SmartCard is no
immune to this. A brute force attack doesn't need to read the card, and
it simply enumerates keys in the key space used by the SmartCard. What
you said--limiting the number of reads on the card--is not a measure
against brute force. It is a measure to prevent reading secret materials.

-- 
Thanks,
Lou



___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: ways to ensure that GPG public key belongs to right person in business to business communication

[Lou Wynn]

Let me analyze your steps to see what you'd like to achieve in each of them.

0. Alice and Bob knows each other's email addresses: alice@A and bob@B.

1. Bob sends Alice his public key at Alice email address alice@A.

2. Alice relies to Bob with her public key.

3. Alice calls B's support and asks to get Bob on the phone.

4. Bob tells Alice the fingerprint of his public key, and Alice checks
it against what she received at (1).

5. Alice tells Bob her public key fingerprint, and Bob verifies it.

You try to use step 4 and 5 to verify step 1 and 2, but it doesn't work.
Suppose that Ted sends Alice his public key impersonating Bob by a faked
from address but replies to Ted. Ted can be B's support guy who answers
phones. Then your method makes Alice think that Ted is Bob. Step 4 and 5
don't add much value because Bob's public key fingerprint is public, and
the guy in Step 3 doesn't have to be Bob. Basically, step 3 is useless,
and step 4 and 5 are like PGP's web of trust: if someone says Bob's has
that public key, then let's just believe it.

The real value starts with 0, which makes Alice believe that she knows
the owner of email of bob@B when sending to that address. The same holds
true for Bob. In step 2, you should make Alice send her public key to
the bob@B address because that's all the knowledge she has about Bob in
terms of reachability, not reply.

I'm working on a PGP key management system for organizational email
communication. In this system, what I verify is not the identity of a
person; instead, it's the owner of an email address. When I send to an
email address with some secret and get the reply, then I know that I've
been in contact with the owner of the email. I don't care about the real
name of the person who owns the email, or I don't care if it's a shared
email used by several people. All I care about is that I've been in
contact with the email address. The security of organizational email
system starts from here. If you're interested in this concept and trying
out this system, I'll be happy to introduce you more, but it's off topic
to this thread.

Thanks,

Lou


On 10/27/2016 01:52 PM, Martin T wrote:
> Hi,
>
> thanks for reply! Unfortunately, Alice and Bob cannot meet in person
> because of geographical distance. If they could, then this would
> definitely be the best way to exchange public keys. I further
> simplified my initial idea:
>
> Alice from company A asks Bob from company B to send her Bobs public
> key using an e-mail. Both Alice and Bob know each other e-mail
> addresses because they have been in contact before during a project
> which involves both company A and company B. Now when Alice receives
> Bobs public key, she will send hers in return to same e-mail address
> which she received the Bobs public key. Then she looks up the phone
> number of the customer support department of company B from company B
> official website and calls there and asks for Bob. Once she gets Bob
> on the phone, she asks Bob to tell the fingerprint of his public key
> and then Alice tells her public key fingerprint to Bob and asks Bob to
> confirm that it matches.
>
> I guess this provides reasonable security?
>
>
> thanks,
> Martin
>
>
> On Wed, Oct 26, 2016 at 11:51 PM, Daniel Kahn Gillmor
>  wrote:
>> Hi Martin--
>>
>> On Wed 2016-10-26 16:21:48 -0400, Martin T wrote:
>>
>>> let's say that Alice from company A and Bob from company B need to
>>> exchange some private data with each other. Alice and Bob need to
>>> encrypt data just that one time, they do not belong to web-of-trust,
>>> but both company A and company B websites are trusted by certification
>>> authority, secure and available only over TLS. This gives a first
>>> option where both Alice and Bob ask their IT departments to publish
>>> their public keys on the company website so Alice can get Bobs public
>>> key over TLS from company B website and the other way around. Or when
>>> for example website of company B is not trusted by CA, then Alice can
>>> pick up the phone, call the customer-support of the company B and ask
>>> for Bob and then ask Bob to send her an e-mail with a public key and
>>> verify the fingerprint of the public key over a phone? Are there
>>> better(easier to use or more secure) ways to ensure that GPG public
>>> key belongs to right person in business to business communication?
>> It depends on how much involvement you want the IT department to have.
>>
>> There are a few more options:
>>
>>  * if Alice and Bob can meet in person, they can give each other
>>business cards with their fingerprints on them.  If this is how Alice
>>finds Bob's e-mail address in the first place, this is a natural
>>place to exchange cryptographic details as well.
>>
>>  * the two companies could use WKD (web key directory), which is in its
>>infancy, but is at least supported by GnuPG 2.1.x.
>>
>>  * Alice and Bob could submit their keys to a third-party notary like
>>Symantec's PGP 

Re: Smartcards and tokens

[Lou Wynn]

Hi Martinho,

After I thought about it more, I have kind of drawn the conclusion that
even for signing, only using a SmartCard cannot achieve authenticity.

With a write-only SmartCard which computes signature on the card, it's
true that it can protect the signing key. However, if it's used in a
hacked machine or malicious environment, the hash sent to the card can
be modified to be the hash of something else, not the hash of the
document that you think you're reading on screen. Even if your signing
key is kept secret on the card, but it blindly signs a fake hash. What's
good about this?

So using a write-only SmartCard alonewithout a secure host environment
cannot give you the security level you think you get. Unless I missed
something from your original description.

This actually boils down a minimal trusted computing base (TCB).
SmartCard itself does not form a complete TCB, which must include
certain trusted host environment.



On 12/15/2016 11:24 AM, Lou Wynn wrote:
>
> If the host machine is compromised, what's the purpose of doing
> encryption on the SmartCard? Attackers don't need to know the key to
> get your plaint ext, because it is on the host machine.
>
> I guess that what you meant was signing, using a SmartCard to sign has
> the benefits you mentioned, but not encryption.
>
>
> On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote:
>> There's an important distinction to be made between using this
>> approach and using a SmartCard. The encrypted USB drive approach
>> leaks the keys into the machine you're using it from; they're
>> accessible by simply reading the filesystem (thus the claim that
>> "When you unplug the USB, your keys are gone." is wrong).  The keys
>> in a SmartCard are write-only; the SmartCard performs all the
>> encryption on-chip.
>>
>> You need to have an attack on the SmartCard to get the keys, while
>> with the USB drive approach, you just need to attack the host machine.
>>
>>
>> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:
>>>
>>> I've come cross a simple and secure approach at this post:
>>>
>>> http://zacharyvoase.com/2009/08/20/openpgp/
>>>
>>> In the MAKING BACKUPS section, this method simply places your gnupg
>>> directory in an encrypted usb drive and make a symlink to it like this:
>>>
>>> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>>>
>>> That's all. As long as you use a good passphrase, this is very
>>> secure method to me. When you unplug the USB, your keys are gone. If
>>> your USB drive is lost, its content is encrypted by your passphrase,
>>> so no worry about it.
>>>
>>>
>>>
>>>
>>> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
>>>> sivmu <si...@web.de> <mailto:si...@web.de> wrote:
>>>>
>>>>> One question remaining is what is the difference between the openpgp
>>>>> smartcard and the USB based tokens.
>>>>>
>>>> I think that the OpenPGP card (the physical smartcard) is included in
>>>> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
>>>> smartcard.
>>>>
>>>> When you want to use a smartcard, you need a card reader to access the
>>>> card.  And the card reader you use would bring another attack vectors.
>>>> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
>>>>
>>>> IIUC, Yubikey products are JavaCard implementations and somehow emulate
>>>> OpenPGP card protocol by "app", and they work as CCID card reader +
>>>> OpenPGP card.
>>>>
>>>> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
>>>> is implemented by Gnuk, the software.
>>>>
>>>>
>>>>> Also how much would you trust those vendors and can the use of such
>>>>> tokens actually decrease security?
>>>>>
>>>> This is the point.
>>>>
>>>> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
>>>> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
>>>> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
>>>> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
>>>> should consider possibility of backdoor of OpenPGP card.  Well, I don't
>>>> know about Yubikey.
>>>>
>>>> When it is replaced to be malicious one to enable an access by others
>>>> (to your private keys), or it already has a backdoor in the first place,
>

Re: Smartcards and tokens

[Lou Wynn]

If the host machine is compromised, what's the purpose of doing
encryption on the SmartCard? Attackers don't need to know the key to get
your plaint ext, because it is on the host machine.

I guess that what you meant was signing, using a SmartCard to sign has
the benefits you mentioned, but not encryption.


On 12/15/2016 01:24 AM, R. Martinho Fernandes wrote:
> There's an important distinction to be made between using this
> approach and using a SmartCard. The encrypted USB drive approach leaks
> the keys into the machine you're using it from; they're accessible by
> simply reading the filesystem (thus the claim that "When you unplug
> the USB, your keys are gone." is wrong).  The keys in a SmartCard are
> write-only; the SmartCard performs all the encryption on-chip.
>
> You need to have an attack on the SmartCard to get the keys, while
> with the USB drive approach, you just need to attack the host machine.
>
>
> On Thu, Dec 15, 2016, at 08:34 AM, Lou Wynn wrote:
>>
>> I've come cross a simple and secure approach at this post:
>>
>> http://zacharyvoase.com/2009/08/20/openpgp/
>>
>> In the MAKING BACKUPS section, this method simply places your gnupg
>> directory in an encrypted usb drive and make a symlink to it like this:
>>
>> ln -s /Volumes/EncDrive/gnupg ~/.gnupg
>>
>> That's all. As long as you use a good passphrase, this is very secure
>> method to me. When you unplug the USB, your keys are gone. If your
>> USB drive is lost, its content is encrypted by your passphrase, so no
>> worry about it.
>>
>>
>>
>>
>> On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
>>> sivmu <si...@web.de> <mailto:si...@web.de> wrote:
>>>
>>>> One question remaining is what is the difference between the openpgp
>>>> smartcard and the USB based tokens.
>>>>
>>> I think that the OpenPGP card (the physical smartcard) is included in
>>> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
>>> smartcard.
>>>
>>> When you want to use a smartcard, you need a card reader to access the
>>> card.  And the card reader you use would bring another attack vectors.
>>> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
>>>
>>> IIUC, Yubikey products are JavaCard implementations and somehow emulate
>>> OpenPGP card protocol by "app", and they work as CCID card reader +
>>> OpenPGP card.
>>>
>>> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
>>> is implemented by Gnuk, the software.
>>>
>>>
>>>> Also how much would you trust those vendors and can the use of such
>>>> tokens actually decrease security?
>>>>
>>> This is the point.
>>>
>>> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
>>> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
>>> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
>>> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
>>> should consider possibility of backdoor of OpenPGP card.  Well, I don't
>>> know about Yubikey.
>>>
>>> When it is replaced to be malicious one to enable an access by others
>>> (to your private keys), or it already has a backdoor in the first place,
>>> it kills the purpose of USB security token.
>>>
>>> Here, the question is: how can we build up such a "trust"?
>>>
>>> It seems for me that there are two different approaches; (1) physical
>>> difficulty (for example, plastic molding for "protection"), (2)
>>> reproducibility and transparency/openness.  Note that some method of
>>> former makes latter difficult.
>>>
>>>
>>> For myself, I take (2), and I did my best to make my product as
>>> reproducible.  (Since I don't manufacture semiconductor things,
>>> reproducibility is not 100%, and this part of manufacturing and
>>> technology is not open at all.)  And I intentionally deliver my product
>>> in a style of "transparent" or "open".
>>>
>>> Distribution channel is also difficult.  I do in person, and I ask FSF
>>> for my TRNG.  Are there any good method?
>>>
>>> Obvious drawback of the apporoach (2) is that people with enough
>>> concern/attention have tendency to do it under their control.
>>> Reasonable.  Since it's reproducible (somehow), it's possible, by
>>> definition.  And then, I can't sell many.
>>>
>>
>> _
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org <mailto:Gnupg-users@gnupg.org>
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Smartcards and tokens

[Lou Wynn]

I've come cross a simple and secure approach at this post:

http://zacharyvoase.com/2009/08/20/openpgp/

In the MAKING BACKUPS section, this method simply places your gnupg
directory in an encrypted usb drive and make a symlink to it like this:

ln -s /Volumes/EncDrive/gnupg ~/.gnupg

That's all. As long as you use a good passphrase, this is very secure
method to me. When you unplug the USB, your keys are gone. If your USB
drive is lost, its content is encrypted by your passphrase, so no worry
about it.



On 12/14/2016 05:35 PM, NIIBE Yutaka wrote:
> sivmu  wrote:
>> One question remaining is what is the difference between the openpgp
>> smartcard and the USB based tokens.
> I think that the OpenPGP card (the physical smartcard) is included in
> Nitrokey Pro USB Token.  So, it's exactly same from the view point of
> smartcard.
>
> When you want to use a smartcard, you need a card reader to access the
> card.  And the card reader you use would bring another attack vectors.
> In this point, Nitrokey Pro USB Token is the best approach, I suppose.
>
> IIUC, Yubikey products are JavaCard implementations and somehow emulate
> OpenPGP card protocol by "app", and they work as CCID card reader +
> OpenPGP card.
>
> In Nitrokey Start USB Token, there is no OpenPGP card physically, but it
> is implemented by Gnuk, the software.
>
>> Also how much would you trust those vendors and can the use of such
>> tokens actually decrease security?
> This is the point.
>
> The hardware OpenPGP card in Nitrokey Pro USB Token could be replaced by
> man in the middle (or its vendor).  The hardware MCU chip in Nitrokey
> Start USB Token could be replaced, too.  The software (Gnuk) in Nitrokey
> Start USB Token could be replaced (with JTAG/SWD debugger), too.  Or, we
> should consider possibility of backdoor of OpenPGP card.  Well, I don't
> know about Yubikey.
>
> When it is replaced to be malicious one to enable an access by others
> (to your private keys), or it already has a backdoor in the first place,
> it kills the purpose of USB security token.
>
> Here, the question is: how can we build up such a "trust"?
>
> It seems for me that there are two different approaches; (1) physical
> difficulty (for example, plastic molding for "protection"), (2)
> reproducibility and transparency/openness.  Note that some method of
> former makes latter difficult.
>
>
> For myself, I take (2), and I did my best to make my product as
> reproducible.  (Since I don't manufacture semiconductor things,
> reproducibility is not 100%, and this part of manufacturing and
> technology is not open at all.)  And I intentionally deliver my product
> in a style of "transparent" or "open".
>
> Distribution channel is also difficult.  I do in person, and I ask FSF
> for my TRNG.  Are there any good method?
>
> Obvious drawback of the apporoach (2) is that people with enough
> concern/attention have tendency to do it under their control.
> Reasonable.  Since it's reproducible (somehow), it's possible, by
> definition.  And then, I can't sell many.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: What is pubring.kbx?

[Lou Wynn]

I just happened to read this page today, and it's still open in my browser.

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html#GPG-Configuration


~/.gnupg/pubring.kbx
The public keyring using a different format. This file is sharred with
gpgsm. You should backup this file.

Cheers

Lou


On 12/09/2016 10:49 PM, Teemu Likonen wrote:
> I just noticed that a couple of days ago a new file ~/.gnupg/pubring.kbx
> had appeared (or last modified). Who made it and what is it for? I'm
> using GnuPG 2.0.26 and its manual doesn't seem to tell anything about
> this file. Obviously I have ~/.gnupg/pubring.gpg too.
>
> $ gpg2 --no-default-keyring --keyring ~/.gnupg/pubring.kbx --list-keys
> gpg: [don't know]: invalid packet (ctb=00)
> gpg: keydb_search_first failed: Invalid packet
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



0xE6CE3473.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users