borando

When your tools are secure, they work for you and not the other way around.

Let me preface my response by saying I think there are probably more non-malicious (accidental) vulnerabilities than intentional backdoors.

Schneier has seen many of the original documents, and his constant refrain is that NSA programs are robust -- that they have multiple totally unrelated ways to accomplish any one goal. Quoting one of his articles:

"First and foremost, the surveillance state is robust. It is robust politically, legally, and technically. I can name three different NSA programs to collect Gmail user data. These programs are based on three different technical eavesdropping capabilities. They rely on three different legal authorities. They involve collaborations with three different companies. And this is just Gmail. The same is true for cell phone call records, Internet chats, cell-phone location data."

https://www.schneier.com/essay-469.html

The takeaway is that, knowing the NSA has capability A doesn't prove they lack capabilities B, C, D...Z.

Sure, the root and major TLDs are anycasted across the globe, but the "wide range" of organizations are just mirroring content that is in one way or another controlled by world governments, and given (for example) ICE domain seizures, it would be prudent not to over-rely on DNS. Personally I support DNSCurve as a means to secure DNS, not to replace security we already have elsewhere.

OpenBSD can do this by default. Just build your package how you like, and then on the target machines, set $PKG_PATH to your build/hosting server.

http://www.openbsd.org/55.html

Regarding ports, they're basically a compilation build system that complements binary packages (which OpenBSD also has) for 3rd party software not installed with the base system . See:

http://www.openbsd.org/faq/faq15.html#Ports

You're missing the major point: MinimaLT will initially use X.509 (since it's already deployed). A future protocol upgrade will support, if I'm not mistaken, sayI.

DNS Security (e.g. DNSCurve, DNSCrypt, or even DNSSEC) adds a second layer of security: keys are transmitted in DNS records, and server auth is done via X.509.

This means an attacker would have to break both X.509 _and_ DNS.

I'm not sure if this is more secure; in fact, I think it's less secure than SSL

I believe the above point addresses your concern. In addition, MinimaLT's Curve25519 + Salsa20-Poly1305 is superior to any ciphersuite found in TLS.

The IETF writes RFCs which developers are expected to follow, and (mostly) do. This is a standardization of sorts, but it's beside the point I was making.

I'm not talking about Joan Daemen wrt BULLRUN. I'm referring to secure protocols that offer RC4 but not Salsa20, TLS without a single constant time cipher, 112-bit security, secure protocols that aren't even encrypted, null ciphers, Dragonfly, cipher suites so complex that they're expected to be implemented wrongly, secure protocols made so complex they won't be used at all, crypto advisory groups run by NSA employees, etc.

I also hope to see more non-standard crypto and protocols, where "the market" leads the way, and standards groups try to keep up in order to appear legitimate.

Just a reminder, this thread is about Xorg running without privileges on OpenBSD -- an amazing feat!

This is incorrect; bcrypt has a 72-character limit. Try this in python:

  import bcrypt, sys

  salt = "$2a$10$2TmO7iAhRfimvNwvpBn.7e"
  print bcrypt.hashpw(sys.argv[1], salt)

  $ python pass.py 12345678901234567890123456789012345678901234567890123456                                                                     
  $2a$10$2TmO7iAhRfimvNwvpBn.7e701F3mp2Z7fpuY/4lu6vUUkrlMEmMou
  $ python pass.py 123456789012345678901234567890123456789012345678901234567
  $2a$10$2TmO7iAhRfimvNwvpBn.7ejJV9jpN0Ahp2RmNAdUGaRxRZndRAs9y

  $ python pass.py 123456789012345678901234567890123456789012345678901234567890123456789012                                                     
  $2a$10$2TmO7iAhRfimvNwvpBn.7e9w2f6/fKQ2QBu1eaIXp4A1WheruxtGK
  $ python pass.py 1234567890123456789012345678901234567890123456789012345678901234567890123
  $2a$10$2TmO7iAhRfimvNwvpBn.7e9w2f6/fKQ2QBu1eaIXp4A1WheruxtGK

True, but: Beware! Imagine you're doing bcrypt in C, and the first sha256 output byte is a 0-byte. bcrypt() sees the NUL / empty password and produces a hash trivially breakable by anyone aware of this issue. :-)

So I'd recommend doing Base64 on the sha256 hash, if you're using C and you want such long passwords with bcrypt. But plain bcrypt will give the best results.

Hopefully the above illustrates the general wisdom of avoiding DIY crypto of any kind.

edit: code formatting

DNSSEC doesn't do encryption. This is why DNSSEC isn't censorship-resistant.

If you want encrypted DNS, that's what DNSCurve does.