Re: Protecting encryption server

[Ángel]

On 2020-07-28 at 18:22 -0700, Ayoub Misherghi via Gnupg-users wrote:
> Before that happens. I am coding a prototype right now that is not going 
> to be inadequate; but all this will help me arrive at a better 
> understanding, help demonstrate basic ideas and hopefully prepare me and 
> others for the production of a better specifications, better action and 
> better product.

Please do not take offense at this, but I think you are way off-track
with how you are exploring solutions. I suspect a good solution should
go through a different venue.

This includes the diode proposal in the thread. It works for limited use
cases such as the voting system, but I don't think it could serve well
for «Client programs access server(s) for real-time encryption or
decryption».

However, at this point I think the real problem has not been specified
properly, and so we lack enough information to properly think what you
might need.

And I think you are way earlier than a prototype phase. In fact, it can
be detrimental in that it can be leading the proposing solutions on one
way, while there could be a better one (plus the cost of preparing a
useless prototype). You should have at least a rough idea on what the
design will involve before preparing a prototype.*


* Actually, on a system you will find *several* designs. It's fine to
code a prototype of the UI with little knowledge on how the backend will
be designed, it might be enough to know the basic that there will be a
username and password, and code from that to start exploring how to
integrate it with the rest of $ENVIRONMENT.
OTOH, if that small premise happens to be wrong (let's say there are no
user and password fields, it's all passwordless authentication based on
SAML single-sign-on at a different portal, to whom the users
authenticate using FIDO keys) that prototype would be of no use.


Regards


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

Re: Yubikey : ed25519 signing failed

[Ángel]

On 2020-07-29 at 11:26 +0200, Julien Escario via Gnupg-users wrote:
> Hello,
> It seems I found a bug in ed25519 key yubikey's support.
> 
> Long story short :
> * Generate a ed25519 Gnupg key and 3 subkeys
> * Generate an ed25519 ssh key pair (SSH authority)
> * Generate a SSH certificate by signing your public key (from Gnupg)
> with your SSH authority
> 
> => When deploying SSH authority public key in authorized_keys on a
> server (with leading cert-authority), you can login with your ssh
> certificate + private key.
> 
> Now, move 3 subkeys to the Yubikey (5.2.6 firmware here).
> 
> => You can't login anymore with message :
> sign_and_send_pubkey: signing failed for ED25519 "~/.ssh/id_ed25519":
> agent refused operation
> 
> To me, it seems the Yubikey is lacking (or buggued) signing operation
> for ed25519 key. I've not been able to debug more deeper, out of my
> understanding.
> 
> Setting directly the ed25519's public key inside authorized_keys file
> works like a charm.

You probably meant "~/.ssh/id_ed25519", not authorized_keys.


> It could also be at the scdaemon or gpg-agent level.
> 
> Anyone already encountered this error ?
> I'm probably the only one in the world to try using a ed25519 SSH cert
> authority with ssh keys on a Yubikey ;-)
> 
> Thanks for your advices !
> Julien

I don't think it will end up being a Yubikey problem. Is signing a
message with a ed25519 key stored in the yubikey working?

Signing a message or an authentication attempt should make no difference
for the Yubikey.

Can the agent/scdaemon open the device in order to communicate with the
Yubikey? Some permission issues end up as the generic "agent refused
operation" errors from the client pov, but they end up being silly
things like lack of rights to open a /dev/ file, such as the pinentry
unable to open the tty.

Best regards



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

Re: Why is there no secret key?

[Peter Lebbing]

On 27/07/2020 22:53, Ayoub Misherghi wrote:
> With API I mean something like GPGME.

It seems to me that including options in gpg.conf that GPGME does not
expect people to put there might throw it out of whack.

> 1) It is preferable to have "--batch" on command line even in
> unattended operation; and not in the gpg.conf file?

Precisely when you do unattended operation should you have it on the
command line. And it should not be in your gpg.conf.

Why do you say "_even_ in unattended operation"?

> 2) --pinentry-mode when needed goes in gpg.conf

No, it makes more sense to specify this on the command line in the
instances you actually need this. However, I explained two methods[1] of
seeding the passphrase, neither of which uses --pinentry-mode.
--pinentry-mode is a great way to shoot oneself in the foot
security-wise.

> 3) --allow-loopback-pinentry when needed goes in gpg-agent.conf

It's already the default, if you want to disallow it you would specify
--no-allow-loopback-pinentry.

Please see the man page.

> Is it true that command line parameters only go to gpg and gpg-agent?

I don't really understand the question.

Usually, you only specify command line parameters to gpg. gpg might
launch a gpg-agent, or connect to an already running instance. There
are gpg command line parameters that influence the command line used to
launch gpg-agent, but in general, gpg's parameters do not propagate to
gpg-agent.

They each have their own set of parameters, documented in the man pages
gpg(1) and gpg-agent(1) respectively. GnuPG consists of more binaries,
but those two are the major ones.

HTH,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2020-July/063825.html

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 



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