similar to: Why still no PKCS#11 ECC key support in OpenSSH ?

On Sun, 12 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Tone aside, let me second what Bob said. OpenSSH maintainers seem to > be able to find time for many updates and upgrades - but ECC support > over PKCS#11 appears to repulse them for more than two years (I don't > care to check for exactly how many more). There's no "repulsion" involved, just a lack of

PKCS#11 support for ECC should have been integrated years ago. Let's not complicate it now, just integrate the existing patches so that people stuck with EC keys at least can use them somehow... Jan Sent from my iPhone > On 14 Aug 2018, at 17:04, Ben Lindstrom <mouring at offwriting.org> wrote: > > Wasn't there a proposal at one time to create something like

On Mon, 13 Aug 2018, Blumenthal, Uri - 0553 - MITLL wrote: > Lack of time on the Open Source projects is understandable, and not uncommon. > > However, PKCS11 has been in the codebase practically forever - the ECC > patches that I saw did not alter the API or such. It is especially > non-invasive when digital signature is concerned. > > Considering how long those patches have

https://bugzilla.mindrot.org/show_bug.cgi?id=2474 Bug ID: 2474 Summary: Enabling ECDSA in PKCS#11 support for ssh-agent Product: Portable OpenSSH Version: 7.1p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh-agent Assignee: unassigned-bugs

Hello, PKCS#11 is a standard API interface that can be used in order to access cryptographic tokens. You can find the specification at http://www.rsasecurity.com/rsalabs/node.asp?id=2133, most smartcard and other cryptographic device vendors support PKCS#11, opensc also provides PKCS#11 interface. I can easily make the scard.c, scard-opensc.c and ssh-agent.c support PKCS#11. PKCS#11 is

On 10/8/2015 4:49 AM, Simon Josefsson wrote: > Mathias Brossard <mathias at brossard.org> writes: > >> Hi, >> >> I have made a patch for enabling the use of ECDSA keys in the PKCS#11 >> support of ssh-agent which will be of interest to other users. > > Nice! What would it take to add support for Ed25519 too? Do we need to > allocate any new PKCS#11

Hi, I have made a patch for enabling the use of ECDSA keys in the PKCS#11 support of ssh-agent which will be of interest to other users. I have tested it with P-256 keys. P-384 and P-521 should work out-of-the box. The code is ready for non-FIPS curves (named or explicit), but OpenSSH currently limits ECDSA to those 3 curves. At high level it works like the support for RSA, but because of

Hello OpenSSH developers, A week ago I've posted a patch that enables openssh to work with PKCS#11 tokens. I didn't receive any comments regarding the patch or reply to my questions. In current software world, providing a security product that does not support standard interface for external cryptographic hardware makes the product obsolete. Please comment my patch, so I can know

Hello everyone, as you could have noticed over the years, there are several bugs for PKCS#11 improvement and integration which are slipping under the radar for several releases, but the most painful ones are constantly updated by community to build, work and make our lives better. I wrote some of the patches, provided feedback to others, or offered other help here on mailing list, but did not

Thomas Calderon <calderon.thomas at gmail.com> writes: > Hi, > > There is no need to add new mechanism identifiers to use specific curves. > > This can be done already using the CKM_ECDSA mechanism parameters (see > CKA_ECDSA_PARAMS > in the standard). > Given that the underlying HW or SW tokens supports Ed25519 curves, then you > could leverage it even with

Hello all, as PKCS#11 URI became standard (RFC 7512), it would be good to be able to specify the keys using this notation in openssh. So far I implemented the minimal subset of this standard allowing to specify the URI for the ssh tool, in ssh_config and to work with ssh-agent. It does not bring any new dependency, provides unit and regress tests (while fixing agent-pkcs11 regress test). The

On Sat, 2020-02-22 at 10:50 -0600, Douglas E Engert wrote: > As a side note, OpenSC is looking at issues with using tokens vs > separate > readers and smart cards. The code paths in PKCS#11 differ. Removing a > card > from a reader leaves the pkcs#11 slot still available. Removing a > token (Yubikey) > removes both the reader and and its builtin smart card. Firefox has a >

[[Sending again, as for some strange reason it is not accepted]] Hello OpenSSH developers, I maintain external patch for PKCS#11 smartcard support into OpenSSH[1] , many users already apply and use this patch. I wish to know if anyone is interesting in working toward merging this into mainline. I had some discussion with Damien Miller, but then he disappeared. Having standard smartcard

Hi all, Thanks for all your hard work! I was particularly excited to see FIDO/U2F support in the latest release. I'd like to make the following bug report in ssh-agent's PKCS#11 support: Steps to reproduce: 1. Configure a smart card (e.g. Yubikey in PIV mode) as an SSH key. 2. Add that key to ssh-agent. 3. Remove that key from ssh-agent. 4. Add that key to ssh-agent. Expected results:

Hello Has any one have any experience in ECC RAM Errors. we are seeing ECC fault Errors but I am not sure if it can be related to RAM it self or it is related to bad connection and noise. please let me know if you have a good document regarding ECC Errors, specially I want to know if data will be retransmitted when error happens. 02:00:31, Thursday, 10/11/2007 : EXCEPTION: ECC Error Interrupt

Hello, The client in question is the latest version of AquaMail running on android. Thanks. Dave. On 7/30/18, Aki Tuomi <aki.tuomi at dovecot.fi> wrote: > You should, in practice, enable both. This gives best client compability. It > is possible you have clients that cannot understand ECC certificates? You > can use ssl_alt_cert to provide RSA cert too. > > Aki >

On 13 December 2016 at 21:00, Kenny Simpson <theonetruekenny at gmail.com> wrote: > Hello, > Is there any support (existing or planned) for host keys/certs being > managed by some hardware device (tpm,hsm,etc..) instead of a flat > file? man ssh search for PKCS#11

Hello, Is there any support (existing or planned) for host keys/certs being managed by some hardware device (tpm,hsm,etc..) instead of a flat file? thanks, -Kenny

Some smartcard readers have keypad to enter the PIN securely (i.e. such that it cannot be intercepted by a rogue (ssh) binary. PKCS#11 allows for enforcing this in hardware. Below patch allows for SSH to make use of this; against head/master as of today. Dw. commit 7f0250a8ae6c639a19d4e1e24fc112d5e2e1249a Author: Dirk-Willem van Gulik <dirkx at webweaving.org> Date: Tue Mar 17

Hello All, As I promised, I've completed and initial patch for openssh PKCS#11 support. The same framework is used also by openvpn. I want to help everyone who assisted during development. This patch is based on the X.509 patch from http://roumenpetrov.info/openssh/ written by Rumen Petrov, supporting PKCS#11 without X.509 looks like a bad idea. *So the first question is: What is the