Displaying 20 results from an estimated 10000 matches similar to: "[Bug 2115] New: Support for DSA p=2048 q=256/224 bit keys"
2013 Sep 10
4
[Bug 1647] Implement FIPS 186-3 for DSA keys
https://bugzilla.mindrot.org/show_bug.cgi?id=1647
mackyle at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mackyle at gmail.com
--- Comment #2 from mackyle at gmail.com ---
RFC 6668 [1] (2012-07) updated RFC 4253 adding the SHA-256 data
2013 Sep 10
4
[Bug 1647] Implement FIPS 186-3 for DSA keys
https://bugzilla.mindrot.org/show_bug.cgi?id=1647
mackyle at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mackyle at gmail.com
--- Comment #2 from mackyle at gmail.com ---
RFC 6668 [1] (2012-07) updated RFC 4253 adding the SHA-256 data
2013 May 28
9
[Bug 2109] New: Add support for ssh-rsa-sha256 and ssh-dsa-sha256 public key algorithms
https://bugzilla.mindrot.org/show_bug.cgi?id=2109
Bug ID: 2109
Summary: Add support for ssh-rsa-sha256 and ssh-dsa-sha256
public key algorithms
Product: Portable OpenSSH
Version: 6.2p1
Hardware: All
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P5
2009 Sep 05
1
[Bug 1647] New: Implement FIPS 186-3 for DSA keys
https://bugzilla.mindrot.org/show_bug.cgi?id=1647
Summary: Implement FIPS 186-3 for DSA keys
Product: Portable OpenSSH
Version: 5.2p1
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: ssh-keygen
AssignedTo: unassigned-bugs at mindrot.org
ReportedBy:
2013 Oct 03
1
ssh-keygen DSA keys longer than 1024 bit
Hi,
Why is there still a limit on the length of a DSA key generated by
ssh-keygen? I mean that ssh-keygen only expects 1024 as key length, or
fails. Here is the code excerpt that enforces the limitation:
if (type == KEY_DSA && *bitsp != 1024)
fatal("DSA keys must be 1024 bits");
Commenting these two lines allows the generation of, say, 2048 bit DSA keys
that work just fine
2013 Sep 10
0
[Bug 1647] Implement FIPS 186-3 for DSA keys
<bugzilla-daemon at mindrot.org> writes:
> https://bugzilla.mindrot.org/show_bug.cgi?id=1647
>
> mackyle at gmail.com changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |mackyle at gmail.com
>
> --- Comment #2 from
2016 Nov 28
2
Inconsistency between legacy and release notes?
On Sat, Nov 26, 2016 at 1:16 AM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
[...]
> Afaik its because DSA key size has (for very weird reasons admittedly:
> FIPS 186-4) been limited to 1024 bits which is considered weak nowadays.
Use of DSA within the SSH protocol requires the use of SHA1, which is
160 bits (80 bits against a birthday attack) and is reaching its
use-by date. This
2013 Sep 10
1
ssh-keygen -t dsa limited to 1024?
Looking at ssh-keygen.c from openssh-6.2p2.tar.gz lines 186-187:
if (type == KEY_DSA && *bitsp != 1024)
fatal("DSA keys must be 1024 bits");
It appears to me that ssh-keygen will only generate 1024 bit DSA keys.
Is that still current?
FIPS 186-3 (2009-06) section 4.2 and FIPS 186-4 [1] (2013-07) section
4.2 state:
4.2 Selection of Parameter Sizes
2019 Oct 17
2
DSA key not accepted on CentOS even after enabling
Hello,
I have some users that connect to a server with their DSA key that is of
type ssh-dss.
I'm migrating (installing as new) the server where they connect to CentOS 8
+ updates.
I was not able to connect with the keys to this new server even after
having added, as found in several internet pages, this directive at the end
of /etc/ssh/sshd_config of the CentOS 8 server:
# Accept also DSA
2018 Oct 10
2
no mutual signature algorithm with RSA user certs client 7.8, server 7.4
Hi,
One of our users who is running an OS (I think it's the latest beta
macOS 10.14.1) with ssh version "OpenSSH_7.8p1, LibreSSL 2.7.3" is
unable to use our user SSH RSA certificates to authenticate to our
servers (which are running "OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan
2017").
We see this error on the client side:
debug1: kex_input_ext_info:
2002 Feb 24
1
RSA versus DSA / Protocol 1 versus Protocol 2
I have been searching the archives and confused about some points that
I am hoping could be cleared up.
RSA versus DSA
I seem to see a lot of messages saying this. That DSA is slow. DSA
was added only to avoid a patent which is now expired. RSA is the
preferred authentification method. DSA should be avoided. Which all
sounds fine to me and I think I agree with that. Assuming this
applies
2019 Jan 19
4
Can we disable diffie-hellman-group14-sha1 by default?
I'm not sure if collision resistance is required for DH key
derivation, but generally, SHA-1 is on its way out. If it's possible
(if there's not a very large percentage of servers that do not support
anything newer), it should be disabled.
2016 Nov 23
2
Inconsistency between legacy and release notes?
Hi,
Someone told me that DSA keys were being deprecated with OpenSSH 7.0. The only reference I could find about this topic on openSSH site is on the legacy page:
?OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.?
There is no explanation about the weakness. But more than that, I could not find any mention
2021 Jan 18
4
[Bug 3253] New: ssh-keygen man page still lists deprecated key types for -t
https://bugzilla.mindrot.org/show_bug.cgi?id=3253
Bug ID: 3253
Summary: ssh-keygen man page still lists deprecated key types
for -t
Product: Portable OpenSSH
Version: 8.4p1
Hardware: Other
OS: Linux
Status: NEW
Severity: minor
Priority: P5
Component: ssh-keygen
2008 Apr 21
3
FIPS 140-2 OpenSSL(2007) patches
Hi,
I am happy to (re)send a set of patches for compiling OpenSSH 4.7p1 with
FIPS 140-2 OpenSSL.
These are based on previously reported patches by Steve Marquess
<marquess at ieee.org> and Ben Laurie <ben at algroup.co.uk>,
for ver. OpenSSH 3.8.
Note that these patches are NOT OFFICIAL, and MAY be used freely by
anyone.
Issues [partially] handled:
SSL FIPS Self test.
RC4,
2020 Feb 05
19
Call for testing: OpenSSH 8.2
Hi,
OpenSSH 8.2p1 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This is a feature release.
Snapshot releases for portable OpenSSH are available from
http://www.mindrot.org/openssh_snap/
The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html
Portable OpenSSH is also available via git using the
instructions at
2018 Oct 11
2
no mutual signature algorithm with RSA user certs client 7.8, server 7.4
On Thu, 11 Oct 2018, Adam Eijdenberg wrote:
> On Thu, Oct 11, 2018 at 12:13 PM Damien Miller <djm at mindrot.org> wrote:
> > Could you try this?
> >
> > diff --git a/sshconnect2.c b/sshconnect2.c
> > index f104408..1d2906f 100644
> > --- a/sshconnect2.c
> > +++ b/sshconnect2.c
> > @@ -1080,7 +1080,8 @@ key_sig_algorithm(struct ssh *ssh, const
2015 Feb 09
3
Connection stalls at debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
Trying to connect from Fedora 21 to CentOS 6.6, OpenSSH on both ends.
Connection is via a VPN.
Initially the connection seems good, but OpenSSH stalls at
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP.
Software version on servers:
openssh-server-5.3p1-104.el6_6.1.x86_64
openssh-5.3p1-104.el6_6.1.x86_64
Software version on client:
openssh-6.6.1p1-11.1.fc21.x86_64
also duplicated problem using
2015 May 23
2
X11 forwarding not working.
Hi!
I'm having a difficult time getting X11 forwarding to work.
Since I've read the docs completely about this, this must be an SSH bug
which is likely because I'm using Gentoo as the SSH server.
When trying to forward X11 connections, I get
X11 connection rejected because of wrong authentication.
kwrite: cannot connect to X server XXXXXXXXX:10.0
Using command
ssh -Y -p 1111 -4
2015 Mar 31
7
Wanted: smartcard with ECDSA support
Hi list,
I have no idea if Damien Miller had the time to work on that.
I have an initial patch to authenticate using PKCS#11 and ECDSA keys.
This requires OpenSSL 1.0.2, prior OpenSSL versions do not expose the
required interfaces to override the signature function pointer for ECDSA.
The only limitation is that the OpenSSL API misses some cleanup function
(finish, for instance), hence I have yet