search for: iacr

Hi there, Has anybody heard of a circular statistics packages/function collection in R (or S-Plus)? (I mean circular statistics for periodic data,(e.g., pointing directions), like the ones described in Batschelet (1980). For example used to compute mean angular deviation and variance, perform comparisons of mean angles using e.g. a Watson-Williams test etc.) I didn't find anything so far,

Here's a recently-published paper that describes a flush & reload attack on OpenSSL's ECDSA implementation: http://eprint.iacr.org/2014/140.pdf According to the authors, snooping a single signing round is sufficient to recover the secret key. --mancha

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

...pher_rekey_blocks(const struct sshcipher *c) +{ + /* + * Chacha20-Poly1305 does not benefit from data-based rekeying, + * per "The Security of ChaCha20-Poly1305 in the Multi-user Setting", + * Degabriele, J. P., Govinden, J, Gunther, F. and Paterson K. + * ACM CCS 2021; https://eprint.iacr.org/2023/085.pdf + * + * Cryptanalysis aside, we do still want do need to prevent the SSH + * sequence number wrapping and also to rekey to provide some + * protection for long lived sessions against key disclosure at the + * endpoints, so arrange for rekeying every 2**32 blocks as the + * 12...

...+cipher_rekey_blocks(const struct sshcipher *c) +{ + /* + * Chacha20-Poly1305 does not benefit from data-based rekeying, + * per "The Security of ChaCha20-Poly1305 in the Multi-user Setting", + * Degabriele, J. P., Govinden, J, Gunther, F. and Paterson K. + * ACM CCS 2021; https://eprint.iacr.org/2023/085.pdf<https://eprint.iacr.org/2023/085.pdf> + * + * Cryptanalysis aside, we do still want do need to prevent the SSH + * sequence number wrapping and also to rekey to provide some + * protection for long lived sessions against key disclosure at the + * endpoints, so arrange for rek...

...ruct sshcipher *c) > +{ > + /* > + * Chacha20-Poly1305 does not benefit from data-based rekeying, > + * per "The Security of ChaCha20-Poly1305 in the Multi-user Setting", > + * Degabriele, J. P., Govinden, J, Gunther, F. and Paterson K. > + * ACM CCS 2021; https://eprint.iacr.org/2023/085.pdf > + * > + * Cryptanalysis aside, we do still want do need to prevent the SSH > + * sequence number wrapping and also to rekey to provide some > + * protection for long lived sessions against key disclosure at the > + * endpoints, so arrange for rekeying every 2**32 b...

...assumptions are just theoretical. Also according to the paper encrypt then-MAC schemes are also vulnerable (which are considered secure): But it is not hard to see that this construction would still be vulnerable to our attacks. There is another paper available: Some Fixes To SSH https://eprint.iacr.org/2013/151.pdf BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they disclose packet length. https://wiki.mozilla.org/Security/Guidelines/OpenSSH Any comments on this? Ciao, Gerhard -- http://www.wiesinger.com/

...ruct sshcipher *c) > +{ > + /* > + * Chacha20-Poly1305 does not benefit from data-based rekeying, > + * per "The Security of ChaCha20-Poly1305 in the Multi-user Setting", > + * Degabriele, J. P., Govinden, J, Gunther, F. and Paterson K. > + * ACM CCS 2021; https://eprint.iacr.org/2023/085.pdf<https://eprint.iacr.org/2023/085.pdf> > + * > + * Cryptanalysis aside, we do still want do need to prevent the SSH > + * sequence number wrapping and also to rekey to provide some > + * protection for long lived sessions against key disclosure at the > + * endp...

...se attacks are rendered infeasible by these changes. https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process SSH implementation comparison http://ssh-comparison.quendi.de/comparison.html Analysis of the SSH Key Exchange Protocol https://eprint.iacr.org/2011/276.pdf

SUBMISSION DEADLINE 14th International Conference on Security and Cryptography Submission Deadline: April 18, 2017 http://www.secrypt.icete.org/ July 24 - 26, 2017 Madrid, Spain. Technically Co-sponsored by IEEE Systems Council. In Cooperation with ITG, IACR. With the presence of internationally distinguished keynote speakers: Charalabos Skianis, University of the Aegean, Greece Carlo Regazzoni, University of Genova, Italy Jan Camenisch, IBM Research - Zurich, Switzerland Jose Duato, UPV, Spain Andreas Holzinger, Medical University Graz, Austria A...

SUBMISSION DEADLINE 14th International Joint Conference on e-Business and Telecommunications Submission Deadline: April 18, 2017 http://www.icete.org/ July 24 - 26, 2017 Madrid, Spain. Technically Co-sponsored by IEEE Systems Council. In Cooperation with ITG, ACM SIGMM, ACM SIGMIS, IACR, EOS, EURASIP. With the presence of internationally distinguished keynote speakers: Charalabos Skianis, University of the Aegean, Greece Carlo Regazzoni, University of Genova, Italy Jan Camenisch, IBM Research - Zurich, Switzerland Jose Duato, UPV, Spain Andreas Holzinger, Medical University Graz...

SUBMISSION DEADLINE 14th International Conference on Security and Cryptography Submission Deadline: April 18, 2017 http://www.secrypt.icete.org/ July 24 - 26, 2017 Madrid, Spain. Technically Co-sponsored by IEEE Systems Council. In Cooperation with ITG, IACR. With the presence of internationally distinguished keynote speakers: Charalabos Skianis, University of the Aegean, Greece Carlo Regazzoni, University of Genova, Italy Jan Camenisch, IBM Research - Zurich, Switzerland Jose Duato, UPV, Spain Andreas Holzinger, Medical University Graz, Austria A...

SUBMISSION DEADLINE 14th International Joint Conference on e-Business and Telecommunications Submission Deadline: April 18, 2017 http://www.icete.org/ July 24 - 26, 2017 Madrid, Spain. Technically Co-sponsored by IEEE Systems Council. In Cooperation with ITG, ACM SIGMM, ACM SIGMIS, IACR, EOS, EURASIP. With the presence of internationally distinguished keynote speakers: Charalabos Skianis, University of the Aegean, Greece Carlo Regazzoni, University of Genova, Italy Jan Camenisch, IBM Research - Zurich, Switzerland Jose Duato, UPV, Spain Andreas Holzinger, Medical University Graz...

Hey, Are there any plans in applying the changes suggested in "Provably Fixing the SSH Binary Packet Protocol" by Mihir Bellare, Tadayoshi Kohno and Chanathip Namprempre. http://eprint.iacr.org/2002/078/ I guess this would require a new protocol specification and maybe the task of the IETF Secure Shell Working Group. Dries -- Dries Schellekens email: gwyllion at ulyssis.org

Hello, On Sat, Dec 30, 2017 at 12:16 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net > wrote: > On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: > > > > Perhaps if you're dead-set on this being so dangerous, > > It's not the developers who are dead-set on weak-keyed RSA being > insecure, it's the cryptanalysts who have shown that to be the

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 passive eavesdropping attacks. > I believe

I was wondering if there was something specific to the internal chacha20 cipher as opposed to OpenSSL implementation. I can't just change the block size because it breaks compatibility. I can do something like as a hack (though it would probably be better to do it with the compat function): if (strstr(enc->name, "chacha")) *max_blocks = (u_int64_t)1 << (16*2);

...1.1.1.9.2.2 src/sys/conf/newvers.sh 1.6.2.2 - ------------------------------------------------------------------------- VII. References <URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0131 > <URL: http://eprint.iacr.org/2003/052/ > <URL: http://www.openssl.org/news/secadv_20030317.txt > <URL: http://www.openssl.org/news/secadv_20030319.txt > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) Comment: FreeBSD: The Power To Serve iD8DBQE+e3s9FdaIBMps37IRAufUAKCTht2X617uI3AB8G/RnRLNvmuF...

.... Vendors of devices that implement the SSH protocol should ensure that they support the new signature algorithms for RSA keys. [1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdf Security ======== * scp(1): when receiving files, scp(1) could be become desynchronised if a utimes(2) system call failed. This could allow file contents to be interpreted as file metadata and thereby permit an adversary to craft a file system that, when copied with scp...

How 'bout PAM? /usr/ports/security/pam_ldap. If you have machines that can't do PAM, perhaps NIS is the way to go (assuming, of course, you're behind a firewall). You can store login information in LDAP like you want, then use a home-grown script to extract the information to a NIS map. Or, if you have a Solaris 8 machine lying around, you can cut out the middle step and use