similar to: Multiple keys/methods per key exchange (e.g. multi-md5-sha1-md4@libssh.org) Re: [PATCH] curve25519-sha256@libssh.org key exchange proposal

Am 02.11.2013 um 11:38 schrieb Aris Adamantiadis <aris at 0xbadc0de.be>: > RFC4251 describes mpint to be multi-size and with positive values having > MSB clear, so it's clearly incompatible with raw string. > > Since you both agreed on the curve25519 implementation to use, I'll work > today on Markus' patch to make the changes Damien wanted. What do you want to

It should be compatible with the original patch. However I think that the shared secret should be encoded as a string, too. What does libssh do? > Am 02.11.2013 um 05:46 schrieb Damien Miller <djm at mindrot.org>: > >> On Fri, 1 Nov 2013, Markus Friedl wrote: >> >> Here are three versions (patch against openbsd cvs) >> >> 1) repace nacl w/libsodium,

if I understand http://git.libssh.org/projects/libssh.git/commit/?id=4cb6afcbd43ab503d4c3d3054b96a1492605ea8d correctly, then the shared secret is encoded as a bignum, probably because the rest of the code assumes it's a bignum (e.g. for key derivation, etc). however, the DH public keys are always encoded as strings (both in my patches and in the libssh.org code). Am 02.11.2013 um 07:57

Here are three versions (patch against openbsd cvs) 1) repace nacl w/libsodium, so i could test 2) curve25519-donna 3) Matthew's public domain reference implementation. i'd vote for #3 -------------- next part -------------- Am 30.10.2013 um 07:27 schrieb Damien Miller <djm at mindrot.org>: > On Tue, 24 Sep 2013, Aris Adamantiadis wrote: > >> Dear OpenSSH

Dear OpenSSH developers, I've worked this week on an alternative key exchange mechanism, in reaction to the whole NSA leaks and claims over cryptographic backdoors and/or cracking advances. The key exchange is in my opinion the most critical defense against passive eavesdropping attacks. I believe Curve25519 from DJB can give users a secure alternative to classical Diffie-Hellman (with fixed

https://bugzilla.mindrot.org/show_bug.cgi?id=2232 Bug ID: 2232 Summary: curve25519-sha256 at libssh.org Signature Failures When 'ssh' Used with Dropbear, libssh Servers Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: major

https://bugzilla.mindrot.org/show_bug.cgi?id=2233 Bug ID: 2233 Summary: curve25519-sha256 at libssh.org Signature Failures When 'sshd' Used with Dropbear Clients Product: Portable OpenSSH Version: 6.6p1 Hardware: All OS: All Status: NEW Severity: major Priority: P5

Hi, So I screwed up when writing the support for the curve25519 KEX method that doesn't depend on OpenSSL's BIGNUM type - a bug in my code left leading zero bytes where they should have been skipped. The impact of this is that OpenSSH 6.5 and 6.6 will fail during key exchange with a peer that implements curve25519-sha256 at libssh.org properly about 0.2% of the time (one in every 512ish

I have developed a compact at the same time high performance library for curve25519/ed25519 and I have placed it in the public domain. It support DH key exchange as well as ed25519 keygen, sign and verify. The implementation is constant-time, supports blinding, bulk-verify and more. The library is available as portable-C as well as ASM for Intel-x64 CPUs. It outperforms curve25519-donna by a

On Tue, 2006-02-21 at 14:58 -0800, rsync2eran@tromer.org wrote: > A year ago we discussed the strength of the MD4 hash used by rsync and > librsync, and one of the points mentioned was that only collision > attacks are known on MD4. Could you please forward this into the bug tracker so it's not lost? -- Martin -------------- next part -------------- A non-text attachment was

I referred to the fact that there is no value for 4096-bit groups at all. For higher strengths than 128 bits one should probably not use non-EC crypto at all, as the document suggests. On Fri, Feb 15, 2019 at 9:19 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 16:45, Yegor Ievlev <koops1997 at gmail.com> wrote: > > That doesn't seem to be

I was reading https://weakdh.org/sysadmin.html They also have a very interesting paper as a PDF. Anyway it appears that most ssh servers, when using DHE key exchange, use the 1024-bit Oakley Group 2 and there is suspicion the NSA has done the pre-computations needed to passively decrypt any tls communication using DHE with that particular prime group. They recommend setting the following:

I don't think there is any point to generate so many moduli. Actually, 3 moduli of sizes 2048, 3072 and 4096 seem like a sane choice. On Fri, Feb 15, 2019 at 7:58 AM Darren Tucker <dtucker at dtucker.net> wrote: > > On Fri, 15 Feb 2019 at 14:22, Yegor Ievlev <koops1997 at gmail.com> wrote: > > I'm not nearly knowledgeable enough in crypto to fully understand your

https://bugzilla.mindrot.org/show_bug.cgi?id=2291 Bug ID: 2291 Summary: ssh -Q kex lists diffie-hellman-group1-sha1 twice Product: Portable OpenSSH Version: 6.7p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component: sftp-server Assignee:

https://bugzilla.mindrot.org/show_bug.cgi?id=2729 Bug ID: 2729 Summary: Can connect with MAC hmac-sha1 even though it's not configured on the server Product: Portable OpenSSH Version: 7.5p1 Hardware: All OS: Linux Status: NEW Severity: security Priority: P5

Hi, I just completed a really big rsync described earlier. Ie about 13,945 directories transfered about 600GB of data. Of 13,945 directories, 13,9441 directories transfer with matching du -b sizes of the preimage to the size of the destination machine image. of the 4 remaining directories i found source vs destination in bytes --------- a) 20480 vs 34922496 b) 28672 vs

Once upon a time, Alice Wonder <alice at domblogger.net> said: > They recommend setting the following: > > KexAlgorithms curve25519-sha256 at libssh.org > > I don't even see that directive in my sshd config to set it, I > suppose it may be one that is manually added when needed but I want > to verify it actually means something in CentOS 7 ssh. > > Also

https://bugzilla.mindrot.org/show_bug.cgi?id=2376 Bug ID: 2376 Summary: Add compile time option to disable Curve25519 Product: Portable OpenSSH Version: 6.8p1 Hardware: Sparc OS: Solaris Status: NEW Severity: enhancement Priority: P5 Component: Build system Assignee:

Since progressmeter.o has moved to libssh, we don't need to explicitly link it into scp and sftp any longer. Index: Makefile.in =================================================================== RCS file: /cvs/openssh/Makefile.in,v retrieving revision 1.255 diff -u -r1.255 Makefile.in --- Makefile.in 10 Feb 2004 02:01:14 -0000 1.255 +++ Makefile.in 11 Feb 2004 17:10:40 -0000 @@ -137,8 +137,8

Hi list, (Please Cc: me in your replies because I'm not subscribed to this list.) While trying to build lukemftpd staticaly on FreeBSD, I got a link-time error. Libssh.a indeed provides the "xmalloc" symbol (I suppose there are more). I wonder if this is whether intentional or not. It is a very common function name, and I think it would be worth renaming it to something like