similar to: Silly question on DH key exch in ssh

Hey all. Apologies if this is the wrong place to post this question. I'm developing an open source Java SSH (v2) client API, and need a bit of help. 1) After receiving the KEXDH_RESPONSE packet, reading SSH Transport Layer Protocol (March 2002), Section 5.2, Output from Key Exchange: do I assume that, in HASH (K || H || "A" || session_id), H is a mpint? The spec states that

Dear all, For my thesis, I've been working on automatic inference of state machines for SSH servers. I ran into a couple of particularities regarding OpenSSH's inferred state machine, and was hoping some of you might be interested. Maybe you can even shed some light on it. Setup: I'm using LearnLib's (Java) version of the L* learning algorithm [1] to come up with sequences of

https://bugzilla.mindrot.org/show_bug.cgi?id=2929 Bug ID: 2929 Summary: OpenSSH server should not send the SSH_MSG_EXT_INFO message after rekeying Product: Portable OpenSSH Version: 7.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

Hello, It seems to me the algorithm negotiation of the transport layer has a bug, it does not follow the specification of draft-ietf-secsh-transport-24, page 19, where the behaviour of first_kex_packet_follows is specified. I've got an ssh client that sends an SSH_MSG_KEXINIT message and specifies only 'diffie-hellman-group1-sha1' as key exchange algorithm. It sets

I have a couple of keys generated using the F-Secure SSH2 client. I have converted those keys using "ssh-keygen -i -f samplekey.txt >> ~/.ssh/authorized_keys". When I try and log into the OpenSSH server using those keys, OpenSSH rejects using those keys. I am under the assumption that this is supposed to work. If I connect using a password, there is no problem. It just does not

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 --- Comment #13 from Darren Tucker <dtucker at zip.com.au> --- (In reply to Christoph Anton Mitterer from comment #10) [...] > Even though an attacker cannot (AFAIU??) for a connection to > downgrade to the weaker groups, The server's DH-GEX exchange hash includes the DH group sizes it received from the client. If these are

https://bugzilla.mindrot.org/show_bug.cgi?id=2302 --- Comment #4 from Damien Miller <djm at mindrot.org> --- Comment on attachment 2630 --> https://bugzilla.mindrot.org/attachment.cgi?id=2630 Make the DH-GEX fallback group 4k bit. Where did this group come from? IMO it would be best to use one of the standard groups if we're picking another fixed one - logjam attacks aren't

https://bugzilla.mindrot.org/show_bug.cgi?id=2303 Bug ID: 2303 Summary: ssh (and perhaps even sshd) should allow to specify the minimum DH group sizes for DH GEX Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5

On Fri 2015-06-12 01:52:54 -0400, Mark D. Baushke wrote: > I have communicated with Allen Roginsky on this topic and I have been given permission to post his response. > > In this message below, the 'vendor' was Darren Tucker's generated prime > that used a generator value of 5. > > -- Mark > > From: "Roginsky, Allen" <allen.roginsky at

On Wed, May 27, 2015 at 05:08:25PM -0400, Daniel Kahn Gillmor wrote: > On Tue 2015-05-26 15:39:49 -0400, Mark D. Baushke wrote: > > Hi Folks, > > > > The generator value of 5 does not lead to a q-ordered subgroup which > > is needed to pass tests in > > > > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf > > I

... is actually old & very well known by the maintainer! there is a bug report for exactly this that is 3 years and 124 days old! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165505 I can also add my report to this bug and mention that we need a fixed version for our xen packages, but as it looks for me (at the moment) the maintainer is not really interessted in getting this

http://bugzilla.mindrot.org/show_bug.cgi?id=567 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |major Component|Build system |ssh-keygen Summary|pb at the end of compil with|ssh-keygen: DH parameter

Hi. I've got the following problem with our SSH client library: - client connects to OpenSSH 5.9+ server and they choose hmac-sha2-512 with diffie-hellman-group-exchange-sha256. - client sends MSG_KEX_DH_GEX_REQUEST DH group request with parameters (1024, 1024, 8192). I.e. minimum and preferred group size is 1024-bit, - OpenSSH server in kexgexs.c:kexgex_server processes this message and

With the default openssh configuration, the selected cipher is aes128-ctr. This means that dh_estimate gets called with bits=128, so dh_estimate selects a DH modulus size of 1024 bits. This seems questionable. Since the NSA seems to be sniffing most internet traffic, keeping SSH sessions secure against after-the-fact offline attack matters, and 1024-bit DH is not convincingly secure against

Hi! Is there any possibility to let dovecot serve >1024 Bit DH Parameters at SSL/TLS-connections? Is it possible to replace /var/lib/dovecot/ssl-parameters.ssl with DH-parameter generated by openssl? If not: Are there any plans to implement that? Thank you!

Hello, from my understanding, using 1024bit DH parameters results in a not sufficiently secure key exchange for DH(E). Therefore I think it would be advisable to have parameters of at least 2048bit . In fact, I would see a great benefit in chosing parameter length arbitrarily. I also do not see the benefit of parameter regeneration. What were the design goals here? Thanks, J?rg L?bbert

I'm using SSL for dovecot, and dovecot kindly warned me on startup that I needed the ssl_dh parameter, which I specified: # grep -P '^ssl_dh' /etc/dovecot/conf.d/10-ssl.conf ssl_dh = </etc/dovecot/dh.pem And I generated the file, as specified in the comment: # openssl dhparam -out /etc/dovecot/dh.pem 4096 The file contains the appropriate headers: # grep -P '^\-'

On 2018-02-19 (14:08 MST), jordan.h at startmail.com wrote: > > I'm using SSL for dovecot, and dovecot kindly warned me on startup that I > needed the ssl_dh parameter, which I specified: doveconf -n -- They say whisky'll kill you, but I don't think it will I'm ridin' with you to the top of the hill

Here's the configuration: https://pastebin.com/ufyQkaBX On Monday, February 19, 2018 7:15:31 PM PST @lbutlr wrote: > On 2018-02-19 (14:08 MST), jordan.h at startmail.com wrote: > > I'm using SSL for dovecot, and dovecot kindly warned me on startup that I > > > needed the ssl_dh parameter, which I specified: > doveconf -n -------------- next part -------------- A

Hi! This change has now been committed, please find it at https://github.com/dovecot/core/compare/cd08262%5E...dd6323.patch Aki On 16.07.2018 09:53, Aki Tuomi wrote: > This is a known issue, but thanks for reporting it. > > > > --- > Aki Tuomi > Dovecot oy > > -------- Original message -------- > From: Eric Toombs <ewtoombs at uwaterloo.ca> > Date: