borando · HackerTrans

hace 12 añosdiscuss

It's refreshing to see the rebrand (RedPhone -> Signal) links security with functionality, rather than with something dramatic/hide-worthy.

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

borando

hace 12 añosdiscuss

Great news! Hopefully between LibreSSL and BoringSSL, OpenSSL will go away and never return. I think AGL and the LibreSSL team will be able to do some fantastic informal collaboration. I'm looking forward to a healthy TLS ecosystem.

borando

hace 12 añosdiscuss

Actually, if anything, the story is proof that the routers are not backdoored from the start

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.

borando

hace 12 añosdiscuss

The data in root "." is controlled by ICANN, a US corporation. The data in the most important gTLD, .com, is run by Verisign on contract with the US Chamber of Commerce. The ccTLDs (.fr, .tw, etc.) are controlled by world governments.

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.

borando

hace 12 añosdiscuss

the ability to easily host your own repository.

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.

borando

hace 12 añosdiscuss

OpenBSD did not upgrade to 2.X. You're talking about ports, which are separate from the base operating system. For accurate information about OpenBSD, right now, check:

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

borando

hace 12 añosdiscuss

This is OpenBSD's fork of Apache 1.3. It runs chroot and privsep'd by default, and of course is patched for security issues where necessary. (OpenBSD recently dropped Apache from the base build and is now fully committed to nginx, moving forward.)

borando

hace 12 añosdiscuss

The system scales up by piggybacking on DNSSEC

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.

borando

hace 12 añosdiscuss

Maybe we're using different definitions of standardization.

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.

borando

hace 12 añosdiscuss

With serious protocol designers now largely side-stepping the IETF due to BULLRUN infiltration, BLAKE2 and other non-standard primitives have a better shot than before of seeing mass adoption. I hope to see BLAKE2 widely used in the future.

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.

borando

hace 12 añosdiscuss

You don't need to run OpenSMTPD in order to get Xorg to work, of course. Also, OpenBSD is just the operating system. You can run whatever MTA you want.

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

borando

hace 12 añosdiscuss

Incidentally Bcrypt does have a 56 byte limit

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)

Nearly identical 56 and 57-char inputs produce different hashes:

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

Nearly identical 72 and 73-char inputs produce identical hashes:

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

you can use longer bcrypt passwords by doing a SHA256 pass

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

borando

hace 13 añosdiscuss

DNS servers which accept both DNSSEC and DNScrypt (based on DNSCurve) encryption.

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

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

comments