Re: Attacks on encrypted communicxatiopn rising in Europe

[Francesco Ariis]

On Tue, Aug 23, 2016 at 10:26:17PM -0400, Robert J. Hansen wrote:
> Some serious questions --
> 
>   1.  Are you a privacy absolutist?
>   2.  If yes, why should we listen to you?

Privacy and its boundaries are a well debated (and well worth to be
debated) topic; keep in mind that any discussion that starts with
framing ("privacy absolutist" is political framing 101 -- would you
feel fairly treated if I described your views on the matter as, say,
"government absolutist"?) is bound to get pretty flamish pretty soon.


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

Re: Attacks on encrypted communicxatiopn rising in Europe

[Robert J. Hansen]

> ... the German and French government are attacking the right to
> encrypt communication of their serfs.

I've got to ask a question.

What would you have us do instead?

For the last eight years I've worked in digital forensics.  That's put
me in a position to see the works of psychopaths up close and personal.
They tend to love photographing or recording their exploits, and their
"art" winds up crossing my desk.  Evil exists and the worst thing I've
ever heard is a wailed, "Daddy, no, please stop!"

I believe that privacy is on balance a good thing and we need good tools
to preserve it.  But I've also seen enough victims and crimes to believe
that we also need ways to detect, apprehend, and prosecute offenders, too.

So long as you're a privacy absolutist -- which it appears you are --
then you're going to be on the losing side of your nation's privacy
debate.  As soon as people hear that your preferred answer to, "So how
should investigators and forensics geeks deal with this Tor, GnuPG, and
cgiproxy-using fiend?" is, "well, he shouldn't, because privacy!",
they're going to write you off as not having anything useful to bring to
the discussion.

Some serious questions --

1.  Are you a privacy absolutist?
2.  If yes, why should we listen to you?
3.  If no, then how should we permit privacy tools to be
circumvented?

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

Attacks on encrypted communicxatiopn rising in Europe

[Johan Wevers]

In
http://www.heise.de/newsticker/meldung/Justiz-soll-verschluesselte-Terror-Kommunikation-auswerten-koennen-3302594.html
(German), the German and French government are attacking the right to
encrypt communication of their serfs. Also because of their violent
anti-encryption opinion I was glad to see the Brittish influence in the
EU shrink but now we have this.

I don't know what they will come up with, but as GnuPG community we
should be prepared because development is in Germany (and we thought to
be safe from the US there...).

Also, Silence. the encrypted sms fork from Signal is developed partly in
France.

Both GnuPG and Silence have the advantage that they are open source and
don't require central servers. Signal has the advantage it's open source
and does not have a commercial presence here that can't be attacked. For
WhatsApp things look not as well.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Security through obscurity (was: OpenPGP Smartcard recommendations)

[Peter Lebbing]

On 23/08/16 12:51, Karol Babioch wrote:
> However for me this mostly applies to the cryptographic concepts itself
> and maybe software implementing them, not necessarily to physical
> devices that have to withstand various forms of physical attacks. When
> it comes to the real world, I'm not sure if this concepts holds
> completely true, though.

My main argument is this: white-hat security researchers would have a
difficult time assessing your design when it is closed.

But that /you/ can't just go and download the design from Yubico does
not mean that nobody can access (steal) or reverse-engineer it. And the
people who do this are often the people you least want to have the
design. They're not the white-hats[1].

People might think that "not available == not available". I don't think
that's accurate.

Lastly, depending on where the company is situated, governments can play
a nefarious role, looking at the design, mandating backdoors. An open
design is better equiped against government mandates than a closed design.

> If the revelations of Snowden taught us anything, than that it is hard
> to implement crypto correctly in the real world. Yes, RSA, AES and such
> are probably computationally secure enough, so that even the NSA cannot
> break it. However, they don't have to, because in the real world there
> are easier ways.
> 
> For the most part, not attacking the crypto system itself is the
> weakness, but various side channels and other indirect vectors like
> that.

So you don't just want to know "this device does RSA", and "RSA is open
and secure". You want to know "it is correctly implemented". When you
can get good security experts to just download your code and design,
they can verify that. When you close the design, your only option is to
approach a handful of researchers and have them look at it under contract.

Bugs might still go unnoticed. Open access is not a panacea. But
"security through obscurity" IMHO pretty much means there are much more
bad guys looking into it than there are good guys.

> This costs them time and
> money, and hence reduces the potential revenue.

But they can sell their knowledge and expertise on a black market...

> [...], but in the end it always comes down to trust, e.g. in this
> case: Do you trust Yubico to have done everything that is reasonably
> possible to protect your keys.

I think they did it to the best of their ability. But I'd like it
independently verified that they actually didn't introduce a bad bug.
All software has bugs.

> Once again I'm not sure if the real world is black-and-white like this.
> Just making something "open source" is not making it secure. Take the
> recent PRNG vulnerability in GnuPG as example (CVE-2016-6313). It was
> there for nearly two decades, and nobody spotted it.

At least, none of the good guys did. I'm not trying to scare anyone. I'm
just saying that if the source was closed, there would be a lot less
good guys to ever do the spotting, and it would be harder to spot for
them. It makes it harder for the bad guys to spot the bugs by not having
the source, but it also makes it harder for the good guys.

> Obviously the same is true for all certifications and a hardware device
> is not secure, just because it is certified. Unfortunately these
> certifications (e.g. things like Common Criteria) are basically the only
> thing we have to make sure a product is designed with security in mind.

This is what I was actually referring to by "a certification stating
some party thinks you're secure"; I just put it a bit starkly for
effect. I'm not convinced CC EAL-blah actually means much. I get this
itchy "designed by committee" feeling, and a feeling of imposed
bureaucracy. So if Common Criteria are actually promoting security
through obscurity, which is what I think the blog post is alluding to...
meh. Stuff your criteria. Just look at in what ways card payments are
broken. Pick any recent Chaos Communication Congress, you'll find a talk
about it, I think. These systems are Common Criteria certified, yet you
can buy a second-hand payment terminal on eBay, enter a store
indentifier that is printed on every receipt of a store, and start
reimbursing payments to cards from that store, payments that were never
done in the first place. It's the reverse of paying at the store: you
put in your card and the store pays you, on your bank account. Methinks
Common Criteria missed a criterium.

> Once again, I'm playing the devil's advocate here. I'm in no way, shape
> or form connected with Yubico and do not want to defend them, but I
> think arguments can be made for both sides here.

Oh, definitely. But I'm convinced that in security, both algorithms and
implementations, an open design is always better than a closed
design.[2] I don't see the algorithm and the implementation as
completely disjoint in this respect. All of the stuff that protects the
secret knowledge, whether it is algorithmic through multiplying the two
secret primes of RSA 

Re: SSH agent prompts for all passphrases

[Karol Babioch]

Hi,

Am 23.08.2016 um 12:03 schrieb Peter Lebbing:
> Or maybe the "Identity*" options in ssh_config help.

After having played around with this for a while, I could solve this in
the following way. I've created a pub file containing the public key of
my smartcard and placed an appropriate IdentityFile directive within the
ssh configuration file, so my smartcards gets now used by default.

Seems to work fine, so I'm quite happy with my setup now.

Thanks again.

Best regards,
Karol Babioch



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

Need Help decrypt HTML E-mail using OutlookPrivacyPlugin

[David J]

Hi,

I've installed dejavusecurity/OutlookPrivacyPlugin to decrypt e-mails from
outlook.

It works well with encrypted text email but under features its says it can
decrypt HTML e-mail.

I'm collecting data from an online form and I want to send the email as a
form with the data filled in.

I encrypt the HTML form using gpg then send as an e-mail.

When the email arrives in Outlook it decrypts but displays at the top:

** Message decrypted. Message was unsigned.

then the HTML code.

Is there any specific way I need to prepare the HTML email then upon
decryption it appears as an HTML email ready for printing.

Any clue as to how I get this to work is welcome.

Thank-you in advance!

David j.



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

Re: OpenPGP Smartcard recommendations

[Alexandre Pujol]

Hi all,

There is also the Nitrokey [1] that like the Yubikey is a smart-card in
a USB stick. However Nitrokey has both software and hardware open source
[2].

Regards,
Alex

[1] https://www.nitrokey.com/
[2] https://github.com/nitrokey


On 23/08/16 01:54, Karol Babioch wrote:
> Personally I absolutely love the YubiKey (4 Nano) [2]. It meets all of
> your criteria and can do a lot more (U2F, PIV, token, HOTP, TOTP, etc.).
> It is also a lot smaller than a real smartcard and can be left in the
> USB port all of the time. The Gemalto USB token (and/or real smartcards)
> are rather unhandy - at least for me.

> 
> P.S.: I should also mention that there is some debate about the open
> source nature of the YubiKey 4, since its firmware is not open to review
> any longer. Should this be a criterion for you, you have to go with
> another solution. You'll find details on the story at [3].
> 

> [2]: https://www.yubico.com/products/yubikey-hardware/yubikey4/
> [3]: https://www.yubico.com/2016/05/secure-hardware-vs-open-source/
> 

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

Re: OpenPGP Smartcard recommendations

[Karol Babioch]

Hi,

since we are commenting here, I want to put out my two cents also, as
this is a topic I'm deeply interested in.

Am 23.08.2016 um 11:17 schrieb Peter Lebbing:
> I was quite surprised by this blog post, by one small but, in my 
> eyes, significant part of it. A lot of the blog post seems not 
> directly related to being able to review the source and verifying 
> that the loaded firmware binary is indeed the reviewed source, which 
> is what would interest me most in a security device.

Yes, this is a problem, and to my knowledge there are no real solutions
to it. Even with software alone its hard to verify that the binary you
are running was indeed built from the correct source (i.e. reproducible
builds), but with firmware and hardware devices it gets pretty much
impossible. Open source is fine and dandy, but it doesn't solve this
problem. And I'm saying this as a big open source enthusiast.

> There's a lot of talk about field-updating firmware securely and 
> related topics, which is only tangential to the source being 
> /available/.

Yes, you are absolutely right and I think the blog post is mixing things
up here. Not making the source available has nothing to do with
field-updatable firmware.

> But the really strange statement is this:
>
> [...]
>
> A secure system is secure by having the knowledge of a secret key.
> It is not secure because most people do not know how it works;
> because the method is secret. This is Cryptography 101. If you want
> to know more, I'd say just use your favourite search engine with the
> phrase "security through obscurity".

I'm playing a little bit of a devil's advocate here. In general I would
agree with your statement. Security by obscurity is a bad idea.  No one
should come up with a new secret encryption standard and claim that it
is secure. It has been shown time and again that these claims are mostly
bullshit. These things should, as you said, be completely open, peer
reviewd, pounded upon and only rely on a secret key.

However for me this mostly applies to the cryptographic concepts itself
and maybe software implementing them, not necessarily to physical
devices that have to withstand various forms of physical attacks. When
it comes to the real world, I'm not sure if this concepts holds
completely true, though.

If the revelations of Snowden taught us anything, than that it is hard
to implement crypto correctly in the real world. Yes, RSA, AES and such
are probably computationally secure enough, so that even the NSA cannot
break it. However, they don't have to, because in the real world there
are easier ways.

For the most part, not attacking the crypto system itself is the
weakness, but various side channels and other indirect vectors like
that. I tend to think that hidden "traps" in a hardware design do
actually improve security, and consider this to be kind of a
defense-in-depth approach. We shouldn't rely too much on "secret
sausage", but it definitely makes things harder for attackers when they
do not know everything about a hardware design and have to reverse
engineer it for themselves. This way key material can be wiped and
hardware destroyed when tampering is detected. This costs them time and
money, and hence reduces the potential revenue.

I think a good analogy is the design of alarm systems and safes. Usually
you won't find too much details about such things and they kind of rely
on the fact that an attacker does not know too much about it.

Obviously there are limits to this and I would like to be convinced
otherwise, but in the end it always comes down to trust, e.g. in this
case: Do you trust Yubico to have done everything that is reasonably
possible to protect your keys.

> Would you rather have a certification stating some
> party thinks you're secure, or would you rather actually be secure?

Once again I'm not sure if the real world is black-and-white like this.
Just making something "open source" is not making it secure. Take the
recent PRNG vulnerability in GnuPG as example (CVE-2016-6313). It was
there for nearly two decades, and nobody spotted it.

Obviously the same is true for all certifications and a hardware device
is not secure, just because it is certified. Unfortunately these
certifications (e.g. things like Common Criteria) are basically the only
thing we have to make sure a product is designed with security in mind.
It makes sure that there are clearly defined goals that can be met,
tested and implemented. It makes sure that the people involved
understand a thing or two about security and products tend to be better
(i.e. more secure) with higher levels of certifications.

Once again, I'm playing the devil's advocate here. I'm in no way, shape
or form connected with Yubico and do not want to defend them, but I
think arguments can be made for both sides here.

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list

SSH agent prompts for all passphrases (was: Deleting SSH key(s) from agent)

[Peter Lebbing]

On 23/08/16 10:46, Karol Babioch wrote:
> However, it is annoying to be prompted for passphrases for each key in
> the keyring. This is even true for cases in which the public key of my
> smartcard is the first and only entry in authorized_keys on a SSH server.

Hm. I use both a smartcard and an encrypted on-disk key, and am
never prompted for a passphrase for a key that isn't listed in
authorized_keys.

You can see a lot of the detail with:

$ ssh -vvv user@host

I can see how the client considers keys, offers them, and only when the
server indicates acceptance will it access the private key and prompt
for a passphrase.

See here how it first asks the server whether it would accept the key
the agent identifies by "/home/peter/.ssh/id_rsa", and the server
declines (that's not very explicit in the messages). I'm not prompted
for the passphrase for that key. The client then offers my smartcard,
and the server accepts. Only then am I prompted for the PIN.

8<->8
[...]
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/peter/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: cardno:00050241
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp
27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1
debug3: sign_and_send_pubkey: RSA
27:f1:31:87:c8:05:5e:30:32:04:61:83:af:f5:8d:a1
[...]
8<->8

Are both the server and the client in your case OpenSSH? Do you have
non-standard options set relating to auth perhaps?

HTH,

Peter.

-- 
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 

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

Re: SSH agent prompts for all passphrases

[Peter Lebbing]

On 23/08/16 11:51, Karol Babioch wrote:
> Can I somehow control the order in which the client presents its keys to
> the server? Is this something the agent controls, or the SSH client itself?

I don't know, but perhaps that's best asked on an SSH mailing list? If
it turns out that the agent has influence (for example because the
client parses the list of keys from the agent top to bottom), then it
would again be something for the GnuPG SSH agent implementation. Perhaps
the order can be influenced through the sshcontrol file, I don't know.
Maybe something changes when you list the keygrip of the smartcard key
in that file.

Or maybe the "Identity*" options in ssh_config help.

> Thanks again for your help, it is very much appreciated.

You're welcome!

HTH,

Peter.

-- 
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 

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

Re: OpenPGP Smartcard recommendations

[Nicole Færber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

as one from kernel concepts I need to apologize for the inconvenience,
we had some major reworks in our infrastrcuture these days. Now things
start to get settled again, mail should work and the website should
also be up again - but there might still be glitches, I am sorry.

We still do supply the cards, worldwide. If you have any questions,
please do not hesitate to contact me by personal email.

Kind regards
  nicole


Am 22.08.2016 um 23:22 schrieb Anthony Papillion:
> Hello Everyone,
> 
> I'm wanting to solidify my key security and I'm just not
> comfortable with having my OpenPGP key on my computer all the time.
> So I'd like to move to a smartcard solution.
> 
> I've gone to the kernelconcepts.de page and tried to contact them
> but it looks like the domain simply isn't accepting mail and the
> site might just be a zombie. So I decided to come here and ask as
> well.
> 
> Can anyone recommend a solid OpenPGP smartcard solution that meets
> the following criteria:
> 
> 1) Supports up to 4096 bit RSA keys 2) Generates keys completely on
> the card 3) Can sign, encrypt, decrypt 4) Preferably has some
> tamper resistence 5) Can import an existing RSA key
> 
> Also, since I'm pretty new to smartcard solutions, I'm also in the 
> market for a reader. If you have any suggestions for one of those,
> I'd appreciate it too. If it makes a difference, I'm in the USA.
> 
> Thanks, Anthony

- -- 
kernel concepts   Tel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
Geschäftsführer: Nils Faerber, Ole Reinhardt
HR Siegen, HR B 9613
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQGcBAEBCAAGBQJXvA7uAAoJEEKL5ZUtJ7x4g3sL/3x88iU46MBf1yyrom3AQyB5
EOT4JTmXo+KgTf/g2COngnOMUU7fh6j6xKqb2UCx6J2CImP3tuUs2fTpqFGYOIb/
3RJUg+332jA/shGMA3+NGyRPochy0Ls3PHV/iPemZ8eDZtv9fu5RwmNCyXParlNd
BJ+Dj+fPUFf5snJED4VVXA0b75fcGYK4zr/3oOUGCaQv49RIduM4sS2Nd+H9ALuf
btWlSrbYeyTdsGqbjA+ttTQ17wWG/Y/ZFI1aj3SLeINz2qc5PmtWoRr67RVpP5b9
Rh5PIWGzv+m12tFbUdLJwHF3Ruj1T3aX+XCR7Yyv0YSy/G2jFtT03cBGBQxj8N7q
3KaXJ0xbmO3v58nUsuD1o9j06z9awqC4W2qVcouA4BDuNCMLBCBEFkyP3jqf9D2l
igKgGzn/izkD7oy1D3PRs7O2WOZPfPMIDjs++qcsj3YJ2phUX+NBGrUDCVE9geO9
iD6JFHipV1Jg6LXihZPDeS+Fe9wFisjLC8SHnUZrTA==
=U4D7
-END PGP SIGNATURE-

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

Re: SSH agent prompts for all passphrases

[Karol Babioch]

Hi again,

Am 23.08.2016 um 11:29 schrieb Peter Lebbing:
> Hm. I use both a smartcard and an encrypted on-disk key, and am
> never prompted for a passphrase for a key that isn't listed in
> authorized_keys.

Ok, it was my mistake. Looking through the verbose output of the SSH
client, I realized that I'm using a jump host, which still had my other
public keys in authorized_keys, so I was being asked for the appropriate
passphrase. Removing them fixed this.

However, there is still something that bothers me. The client offers the
disk-based keys first (id_rsa, id_ed25519, etc.). This is not a problem
in case only the smartcard's key is stored in authorized_keys, but as
soon as I put a fallback key there, it is being offered first and I'm
asked for the passphrase.

Can I somehow control the order in which the client presents its keys to
the server? Is this something the agent controls, or the SSH client itself?

Thanks again for your help, it is very much appreciated.

Best regards,
Karol Babioch



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

Re: OpenPGP Smartcard recommendations

[Peter Lebbing]

On 23/08/16 02:54, Karol Babioch wrote:
> P.S.: I should also mention that there is some debate about the open
>  source nature of the YubiKey 4, since its firmware is not open to 
> review any longer. Should this be a criterion for you, you have to
> go with another solution. You'll find details on the story at [3].

I was quite surprised by this blog post, by one small but, in my eyes,
significant part of it. A lot of the blog post seems not directly
related to being able to review the source and verifying that the loaded
firmware binary is indeed the reviewed source, which is what would
interest me most in a security device. There's a lot of talk about
field-updating firmware securely and related topics, which
is only tangential to the source being /available/.

But the really strange statement is this:

> In this specific context (fault injection and side-channel
> analysis), an open source strategy would provide little or no remedy
> to a serious and growing industry problem. One could say it actually
> works the other way. In fact, the attacker’s job becomes much easier
> as the code to attack is fully known and the attacker owns the
> hardware freely.

I'm with him on the first sentence. The context is broadly that when
your hardware is not secure, no amount of open sourcery would protect
the data the hardware holds. At least if I understood the context.

But then it gets iffy.

The attacker's job becomes easier because he knows the inner workings?
Alert! Alert! Security through obscurity! Prepare for battle stations!

A secure system is secure by having the knowledge of a secret key. It is
not secure because most people do not know how it works; because the
method is secret. This is Cryptography 101. If you want to know
more, I'd say just use your favourite search engine with the phrase
"security through obscurity".

I fully understand that stuff gets complicated when your hardware vendor
forbids you to disclose your source code. That's a nasty problem. I'm
less concerned about not meeting criteria for some certification because
the source is open. Would you rather have a certification stating some
party thinks you're secure, or would you rather actually be secure? I'd
know. Stuff those Common Criteria ;). They're not the holy grail. But
when you say "obscurity helps security", I'm seriously starting to doubt
your reasoning.

My 2 cents,

Peter.

-- 
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 

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

Re: Deleting SSH key(s) from agent

[Karol Babioch]

Hi,

Am 23.08.2016 um 10:36 schrieb Peter Lebbing:
> If I'm mistaken, I'd like to know. But I suspect the system was
> correctly designed to thwart such a thing.

I'm pretty sure you are right, so this is not my concern.

> So I don't think there is a need to ensure the correct key is used.

However, it is annoying to be prompted for passphrases for each key in
the keyring. This is even true for cases in which the public key of my
smartcard is the first and only entry in authorized_keys on a SSH server.

ssh-add -L lists the public key of my smartcard also first in the first
place, so I'm not sure why I always get asked for other keys. On the
other hand I do not want to have keys lying around unencrypted on disk.

I could possibly get away with making a configuration using the
Identity* directives from ssh_config(5), but this seems to be a PITA.

Is it somehow possible for gpg-agent to _NOT_ ask for passphrases it
does not need, e.g. to enforce that the smartcard is tried first for
authentication?

Best regards,
Karol Babioch



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

Re: Deleting SSH key(s) from agent

[Peter Lebbing]

On 23/08/16 10:20, Karol Babioch wrote:
> How are you guys dealing with multiple SSH keys while making sure the
> correct one is being used?

I don't make sure the correct one is used.

The challenge that is signed with your private key is based on data
provided by both the server and the client. I have never heard of an
attack that allowed a challenge for one SSH server to be used as
authentication to a different SSH server. In other words, I've never
heard of an attack where a rogue SSH server can impersonate you on a
different server when you authenticate to the rogue server.

If I'm mistaken, I'd like to know. But I suspect the system was
correctly designed to thwart such a thing.

So I don't think there is a need to ensure the correct key is used.

HTH,

Peter.

-- 
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 

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

Re: Deleting SSH key(s) from agent

[Karol Babioch]

Hi,

Am 21.08.2016 um 12:27 schrieb Peter Lebbing:
> Let me answer by example:

Thank you very much. I even knew about gpg-connect-agent, but didn't
connect the dots. I was too focussed on getting it to work through the
ssh-add interface. It does indeed work as outlined.

However it seems to be more complicated than before, since I need to
keep track of keygrips now. How are you guys dealing with multiple SSH
keys while making sure the correct one is being used?

Best regards,
Karol Babioch



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

Re: AW: OpenPGP Smartcard recommendations

[Anthony Papillion]

This looks exactly like what I'm looking for! Thanks for the
recommendation. Definitely going to get one. Many thanks again.

Anthony

On 8/22/2016 10:38 PM, cornelius.koelbel wrote:
> 
> Hi Anthony,
> 
> You may also take a look at the Nitrokey. Kind regards Cornelius
> 
> 
> Cornelius Kölbel +49 151 2960 1417
> 
> NetKnights GmbH Http://NetKnights. It +49 561 3166 797
> 
> 
>  Ursprüngliche Nachricht  Von: Anthony Papillion
>  Datum: 22.08.16 23:22 (GMT+01:00) An:
> gnupg-users@gnupg.org Betreff: OpenPGP Smartcard recommendations
> 
> Hello Everyone,
> 
> I'm wanting to solidify my key security and I'm just not
> comfortable with having my OpenPGP key on my computer all the time.
> So I'd like to move to a smartcard solution.
> 
> I've gone to the kernelconcepts.de page and tried to contact them
> but it looks like the domain simply isn't accepting mail and the
> site might just be a zombie. So I decided to come here and ask as
> well.
> 
> Can anyone recommend a solid OpenPGP smartcard solution that meets
> the following criteria:
> 
> 1) Supports up to 4096 bit RSA keys 2) Generates keys completely on
> the card 3) Can sign, encrypt, decrypt 4) Preferably has some
> tamper resistence 5) Can import an existing RSA key
> 
> Also, since I'm pretty new to smartcard solutions, I'm also in the 
> market for a reader. If you have any suggestions for one of those,
> I'd appreciate it too. If it makes a difference, I'm in the USA.
> 
> Thanks, Anthony
> 
> 
> ___ 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: OpenPGP Smartcard recommendations

[Anthony Papillion]

Thanks for the reply. I have an older Yubikey Classic and still use it
to this day for a lot of things. It's awesome. I'll definitely take a
look at the newer keys you mentioned and see if they are something I
could use. Thanks for the recommendation.

I might also join the FSFE. Does it matter that I am not in Europe (I'm
in the USA)?

Thanks,
Anthony

On 8/22/2016 7:54 PM, Karol Babioch wrote:
> Hi,
> 
> Am 22.08.2016 um 23:22 schrieb Anthony Papillion:
>> I've gone to the kernelconcepts.de page and tried to contact them but
>> it looks like the domain simply isn't accepting mail and the site
>> might just be a zombie.
> 
> I'm pretty sure you've done something wrong here. I just placed and
> received an order last week.
> 
>> Can anyone recommend a solid OpenPGP smartcard solution that meets the
>> following criteria:
> 
> Besides the smartcards from kernelconcepts, you can also become an FSFE
> member to get such a card [1].
> 
> Personally I absolutely love the YubiKey (4 Nano) [2]. It meets all of
> your criteria and can do a lot more (U2F, PIV, token, HOTP, TOTP, etc.).
> It is also a lot smaller than a real smartcard and can be left in the
> USB port all of the time. The Gemalto USB token (and/or real smartcards)
> are rather unhandy - at least for me.
> 
> Best regards,
> Karol Babioch
> 
> P.S.: I should also mention that there is some debate about the open
> source nature of the YubiKey 4, since its firmware is not open to review
> any longer. Should this be a criterion for you, you have to go with
> another solution. You'll find details on the story at [3].
> 
> [1]: https://fsfe.org/fellowship/card.html
> [2]: https://www.yubico.com/products/yubikey-hardware/yubikey4/
> [3]: https://www.yubico.com/2016/05/secure-hardware-vs-open-source/
> 
> 
> 
> 
> ___
> 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