Daily reminder that pic related uses NIST P-256 by default, a curve that is known to be backdoored by the NSA

Daily reminder that pic related uses NIST P-256 by default, a curve that is known to be backdoored by the NSA.

Enjoy your botnet, "anons"...

Attached: openssh.png (500x492, 38K)

Other urls found in this thread:

openssh.com/
fedoraproject.org/wiki/Changes/CryptoPolicy#System-wide_crypto_policy
tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-10#section-3.12
safecurves.cr.yp.to/
twitter.com/NSFWRedditGif

Holy shit. I thought you must be trolling but this is actually true.

Attached: 1492159890346.jpg (641x530, 41K)

No it doesn't. Recent versions of openssh use djb's ed25519 as their first choice by default. This running code was one factor which ultimately led to the IRTF blessing it. You're probably using X25519 to talk to Cloudflare serving Jow Forums right now, if you have a modern browser.

Also it's a huge stretch to call anything about P-256 a backdoor. Fishy as hell, yes, but backdoored? We can't be confident there isn't one, but we certainly can't point to one and based on all the available evidence, there probably isn't: but there could be, and that possibility alone necessitated replacing the curve with something more 'rigid'.

The provenance of the seed specifying the curve parameters for P-256 (aka prime256v1, aka secp256r1) is unknown, and to date, despite a lot of analysis, nobody has found any specific weaknesses in that curve that are easy to exploit, although there are some general (quite serious) issues with implementing short Weierstrass curves safely such that you avoid invalid point or twist attacks, and other fun like that. That is why we prefer, and IRTF ultimately specified, "safe" curves like djb's Curve25519, and Mike Hamburg's Curve448 (see RFC 7748, 8032, and other related ones).

I do know that Certicom did perform a computational search for the secp seeds, so that those curves could be more efficiently implemented using certain techniques they had patented. I believe the seed is an SHA-1 hash of a number of English words, although given the words were searched for that doesn't give any 'nothing up my sleeve' assurance at all. The NSA were probably involved with supplying computational power for that search: they wanted to use the curves for their own security, licenced the patents, and indeed have used P-384 for TOP SECRET purposes for many years.

>t. theo

OpenBSD is a meme
>Filesystem
default FS doesn't even support SSD TRIM, and I don't think OpenBSD supports anything modern like ZFS or BTRFS.
>Security
"Only two remote holes in the default install!!!!!!!"
Yay!
I hope you realize that this literally only applies to a base system install with absolutely no packages added. In other words, not exactly representative or meaningful towards... anything really
>Sustainability
A few years ago, OpenBSD was actually in danger of shutting down because they couldn't keep the fucking lights on. How could anyone see this as a system they could rely on, when it could be in danger of ending at any time?
>Standards-compliance
"B-But OpenBSD is written in strictly standards-compliant C! Clearly that's better than muh GNU virus!"
So you're not allowed to create extensions to the standard? You should only implement the standard and nothing more? Keep in mind that this is nothing like EEE, as the GNU extensions are Free Software, with freely available source code, as opposed to proprietary shite. People should be allowed to innovate and improve things.
If you're gonna be anal about standards-compliance, then why let people make their own implementations anyway? Why not have the standards organizations make one C implementation and force everyone to use it?

wut? I thought it uses Ed25515 by default. Source?

t.Jow Forums

AP()5:163:324:297:01

>image in OP has filename 'openssh'
>logo is for OpenBSD
>OpenBSD actively maintain a fork of openssh called libressh

Attached: 9d5.png (2688x2688, 173K)

Though I disagree with OP you better check yourself with such a dumb ass post.

that logo is for openssh thought openssh.com/
nope that's fork of openssl called libressl (ssh is remote secure shell protocol, ssl is cryptographic library)

I mostly use ed25519.
The "FUTURE" crypto policy in Fedora ( /usr/share/crypto-policies/FUTURE/openssh-server.txt ) leads to this config
iphers [email protected],[email protected],aes256-ctr,aes256-cbc,[email protected],aes128-ctr,aes128-cbc
MACs [email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha1,hmac-sha2-256,hmac-sha2-512
GSSAPIKeyExchange no
KexAlgorithms [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256
Background about Fedora's Cryptopolicy:
fedoraproject.org/wiki/Changes/CryptoPolicy#System-wide_crypto_policy
ecdh-sha2-nistp256 is the second in Kex ordering, despite tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-10#section-3.12
>given [CNSA-SUITE] and [safe-curves], this
>curve may not be as useful and strong as desired for handling TOP
>SECRET information for some applications. The SSH development
>community is divided on this and many implementations do exist.

cipher agility was a mistake

Can someone explain for someone who has absolutely zero (0) clue on the topic what this is all about? I am genuinly curious!

Attached: 1515318730050.png (500x658, 21K)

I'm not completely sure how true is OP's statement.
OpenSSH needs 2 cipher solutions: one for key exchange and handshake and other for stream encryption. OP's problem is with NIST P-256 elliptic curve encryption for key exchange. NIST is USA organization and authority that is quite known to push encryption standards with NSA backdoors (not a tinfoil conspiracy but fact).
I'm not cryptographer and would have to read something to get better understatement why NIST P-256 is insecure for some scenarios. As mentioned OpenSSH uses Ed25519 curve encryption by default which is made by djb (Daniel J. Bernstein, the true genius of our time and one of the most significant cryptographers currently, he has my unconditioned trust), but OpenSSH received some criticism in past for "cipher agility" where client asks if server supports some cipher suite and if not it tried to downgrade to something less worse (slower or maybe less secure) until it gets a match of what both server and client supports. This is IMHO quite bad design. In early days where there was a huge difference between CPU architectures and some cipher suites were not really viable on certain archs it was possible to not find any match - this problem disappeared with new protocol versions and quite homogeneous current architectures. It as also source of many buts for TLS in past.
djb has some overview for various elliptic curve crypto safecurves.cr.yp.to/ and you can see NIST P-256 doesn't fulfill some requirements, but it's possible it's safe for scenarios OpenSSH would use it for, as I said I'm not cryptographer and would have to read through lots of shit to get better understanding and definitive answer. Sorry.

also fuck auto-correct

AP()MO:RD:A;;C:WE:L::U

>tfw your shit is backdoored

Attached: theoBUTHURT.png (600x600, 280K)

>yes goy don't use that ECC it's backdoored by the spooks

isn't how that's supposed to work? you tellin me we're supposed to poop out of our peenor?

t. CIAnigger

CIAniggers confirmed to use the word goy