search for: adamantiadis

...o openssh-6.3p1 (I think adaptations for OpenSSH are trivial). It links to libnacl. However, my autotools skills are lacking and I compiled it with LIBS=-libnacl. I would greatly appreciate feedback and/or a debate on the relevancy of such kex method, code quality and implementation details. Aris Adamantiadis www.libssh.org -------------- next part -------------- >From c3105fa718ca813a06527a238294c148dfc91287 Mon Sep 17 00:00:00 2001 From: Aris Adamantiadis <aris at 0xbadc0de.be> Date: Tue, 24 Sep 2013 21:59:36 +0200 Subject: [PATCH] kex: implement curve25519-sha256 at libssh.org --- Makefile...

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

Also nice to know that zlib at openssh.com enables the compression only after authentication, mitigating the known problems with compression and passwords. It is also very hard to do chosen-plaintext attacks on the client to server side (in opposite to HTTPS where that's trivial). And most passwords that are typed after authentications are entered character by character, making them fall under

Dear OpenSSH developers, I hope you don't mind that I resubmit my patch for OpenSSH. This patch adds a new ssh_config option "ExecRemoteCommand", which is the missing equivalent to the "-N" command line option. For implementation notes, please have a look at the top of the patch. Regards, Volker -- Volker Diels-Grabsch ----<<<((()))>>>----

Hello, I'm writing from OpenSC project (OpenSSH used to include OpenSC support for smart cards, it has been removed now and PKCS#11 is used instead, whish is nice), we're planning to have a "Security / hardware crypto keys" themed devroom at FOSDEM next year. Are people on this list interested in participating, and trying to tackle the problem of "Why OpenSSH does not work

Hello, Dear SSH developers. I'm currently studying Business Information Technologies at the University of Applied Sciences in Oulu, Finland. I'm about to start my own online computer security related magazine. I would like to make an article about the helpful ssh protocol for security professionals. I have made sequence diagrams on how the SSH 2.0 protocol works, however i'm not sure

Hi Gerhard, This is not exactly true. CTR modes have the length field encrypted. etm MAC modes and AES-GCM have the length field in cleartext. CBC is dangerous because the length field is encrypted with CBC. aes128-ctr + hmac-sha256 doesn't have any known vulnerability and encrypts the packet length, but uses the bad practice of e&m. chacha20-poly1305 encrypts both payload and packet

I am doing a certain analysis with different kinds of traffic and SSH is one of them. I am using SSH Version 2 on the complete test bed. Also, I am doing in depth packet analysis and have landed up with some anomalies. 1. Out of Millions of packet there are about 5 packets that are of odd size. The size is only the data frame size considered after the TCP header has been removed. All other

Hi, mancha and me debugged a problem with OpenSSH 7.3p1 that was reported on the #openssh freenode channel. Symptoms were that this message was popping on the console during a busy X11 session: kex protocol error: type 7 seq 1234 I managed to reproduce the problem, it is related to the SSH_EXT_INFO packet that is send by the server every time it is sending an SSH_NEWKEYS packet, hence after

Dear OpenSSH devs, I came accross this paper yesterday. http://eprint.iacr.org/2011/232 It states that they were able to recover ECDSA keys from TLS servers by using timing attacks agains OpenSSL's ECDSA implementation. Is that known to be exploitable by OpenSSH ? (In my understanding, it's easy to get a payload signed by ECDSA during the key exchange so my opinion is that it is).

...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 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 &gt...

On Tue, Sep 24, 2013 at 10:21 PM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote: [snip] > 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...

Le 06/07/15 12:33, Alex Bligh a ?crit : > On 6 Jul 2015, at 11:05, Christian Hesse <list at eworm.de> wrote: > >> +#ifdef HAVE_LOCALE_H >> + char *locale; >> + char *border_utf8[] = { "?", "?", "?", "?", "?", "?" }; >> +#endif >> + char *border_ascii[] = { "+", "-",

How about using the existing OpenSSH client's PKCS#11 support to isolate keying material in a dedicated process? A similar approach, "Practical key privilege separation using Caml Crush", was discussed at FOSDEM'15 with a focus on Heatbleed [1][2] but the ideas and principles are the same. Now this is easily done using the following available components: - SoftHSM to store

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

A co-worker argues we can login using only password to a "ssh-key restricted host (PasswordAuthentication no)", without being asked by any passphase; just by putting a key (no need to be the private key) on another password-based host. It that true? I do not think so. I would name that as an "important OpenSSH daemon security bug". That is because I think it is not true.