- cypherpunks - lists.cpunks.org

hardened *nix for Lenovo X60
by Eugen Leitl 26 Aug '13

26 Aug '13

I've managed to lay my hands onb a couple of Lenovo X60's that are in pretty good shape and would like to use them as a moderately secure communication/development system. (I'm not trusting my desktops, servers or mobile devices for obvious reasons). I'm loath to modify the hardware at this point, so I expect to only flash coreboot upon it. What kind of security-minded Linux or *BSD would you guys recommend? Liberte looks a bit too stable (cough, sorry Максим)), Kali is more for security h4x0rs. Anything else what is well-maintained yet borderline secure from *untargeted* TLA-level scrutiny? I'm okay with text-mostly distros, or minimalistic window managers. It shouldn't be a kitchensink of stuff I don't need, but on the other hand it's shouldn't be so secure it's unusable, either. Pointers to any HOWTOs or SOPs highly welcome. Tanks & machine guns.

6 7

Re: hardened *nix for Lenovo X60
by John Down 26 Aug '13

26 Aug '13

If so, then worth to have a look at hardened gentoo to have full control over the process how the system is built, what patches are applied, etc On Mon, Aug 26, 2013 at 04:05:25PM +0000, Dan White wrote: > On 08/26/13 17:09 +0200, Eugen Leitl wrote: > > > >I've managed to lay my hands onb a couple of Lenovo X60's that are > >in pretty good shape and would like to use them as a moderately secure > >communication/development system. (I'm not trusting my desktops, > >servers or mobile devices for obvious reasons). I'm loath to modify > >the hardware at this point, so I expect to only flash coreboot > >upon it. > > > >What kind of security-minded Linux or *BSD would you guys > >recommend? Liberte looks a bit too stable (cough, sorry Максим)), > >Kali is more for security h4x0rs. Anything else what is well-maintained > >yet borderline secure from *untargeted* TLA-level scrutiny? > > > >I'm okay with text-mostly distros, or minimalistic window > >managers. It shouldn't be a kitchensink of stuff I don't need, > >but on the other hand it's shouldn't be so secure it's > >unusable, either. > > > >Pointers to any HOWTOs or SOPs highly welcome. Tanks & machine guns. > > The boring recommendation: Debian > > Pros: > * Lots of eyeballs > * Timely security updates (well, timely as far as vendors go) > * A wealth of pre-packed software, which can be twiddled down to size > * Some fancy features out of the box (like remotely booting a LUKS > encrypted root filesystem via an initramfs ssh daemon) > > Cons: > * Patching your locally installed (packaged) software must be done with > Debian build scripts, or you quickly lose the benefits of the apt system > * Stupid patches have made it past the package maintainer (the OpenSSL > 2008 patch being the one that comes immediately to mind) > > If you're willing to compile your own software or security updates, then I > think your choice of OS/distro may be mostly moot. > > I'd recommend against a specialized security (linux) distro, unless you > know what you're doing. Support for many of them seems to be pretty spotty, > according to my unscientific observation from ##linux.

1 0

NSA Head: US Cyber Offense Is Best in World
by John Young 26 Aug '13

26 Aug '13

http://blogs.fas.org/secrecy/2013/08/cyber-offense/ NSA Head: US Cyber Offense Is Best in World "Cyber offense requires a deep, persistent and pervasive presence on adversary networks in order to precisely deliver effects," Gen. Alexander explained in response to a question from Rep. Trent Franks (R-AZ). "We maintain that access, gain deep understanding of the adversary, and develop offensive capabilities through the advanced skills and tradecraft of our analysts, operators and developers. When authorized to deliver offensive cyber effects, our technological and operational superiority delivers unparalleled effects against our adversaries' systems."

1 0

[Cryptography] Formal Verification (was Re: Email and IM are ideal candidates for mix networks)
by Eugen Leitl 26 Aug '13

26 Aug '13

----- Forwarded message from "Perry E. Metzger" <perry(a)piermont.com> ----- Date: Mon, 26 Aug 2013 10:02:54 -0400 From: "Perry E. Metzger" <perry(a)piermont.com> To: Jerry Leichter <leichter(a)lrw.com> Cc: cryptography(a)metzdowd.com, Christian Huitema <huitema(a)huitema.net> Subject: [Cryptography] Formal Verification (was Re: Email and IM are ideal candidates for mix networks) X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.20; x86_64-apple-darwin12.4.0) On Sun, 25 Aug 2013 23:32:32 -0400 Jerry Leichter <leichter(a)lrw.com> wrote: > I think the goal to aim for is no patches! Keep the device and its > interfaces simple enough that you can get a decent formal proof of > correctness, along with a ton of careful review and testing (per > Don Knuth's comment somewhere to "Be careful of the following code, > I've only proved it correct, not tested it") and then *leave it > alone*. I'd like to point out that this is no longer a pipe dream. The formal verification of seL4, CompCert and other substantial pieces of code in recent years shows the technology has improved a lot. Quark (the web browser verified by the use of a "shim") has shown one can get enormous leverage by formally verifying only tiny fractions of an overall system comprising millions of lines of code, which is an especially interesting technique in the context of existing large code bases. Formal verification is not a panacea. One has to know what to verify, for example, and if you verify the wrong properties, you've gained little. However, unlike current methods, if you discover you have failed to verify a needed property, adding a theorem to your development fixes that hole _completely_ and _forever_. (Yes, you also need a verified toolchain, but given things like CompCert, that is now doable.) I'm something of a recent arrival to the world that developed the most widely used tools for formal verification (like Coq), and so I'm in a better position than most to explain how to learn about them. I would be happy to produce an extended post on how to learn about what is out there for people who are interested. Warning: although in the long term there is no reason the tools cannot be made very user friendly and easy to use, right now that is not the case. This is not inherently so, it is just a feature of the development history of the tools. Error messages tend to be pretty poor, as is documentation, and the learning curve is steep. However, in the long run, I'll state very directly I think the recent advances in the state of the art in proof assistants are the most significant new development in software quality in decades. The user unfriendliness could be fixed by a new generation of users and developers who started "further away from the problem". Perry -- Perry E. Metzger perry(a)piermont.com _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Alternatives to Lavabit
by Stakewinner00 26 Aug '13

26 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now that Lavabit is off, we should seek another server with encryption. My question are, there are another encrypted email service like Lavabit? Or we have to create a new encrypted email service? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEVAwUBUhfOC2nZMKDLC/xbAQKUMQgAjls2AY+VZpY4PEudvb5Dc5c+7SOYehHC 8GVDwkXRI+Pp09e3aTK5lYaij7fQZ/aGO3lGnr8Hm7s0xRYig7hpCPiIymJ/O9Kq i0nQibqMrgLTter/7MkIbyjsmAvO1hYE8rbct1snk2JIDjw/gkLi4kzxtMd5h2qn RZoMmAKgZlDou4MUDrpA9iTvRQY8qisB+27wAHgDYxtZzejdr0b2pNZxsaUwOLXv EjASFiBPi07DyZqrDHUArGyiIMQn2sBqEEzmKvUrp4DTm1IT/B6e7A5tUhkDAX7r ThcD2rKK43Kqog+zPogDJ8Hp3lhB7aR0QPTP3ILq7ioKmy+nvnQzOw== =YEFA -----END PGP SIGNATURE-----

2 1

Re: Who bought off Zimmermann?
by Bill Stewart 26 Aug '13

26 Aug '13

At 07:09 PM 8/25/2013, Shawn K. Quinn wrote: >On Sun, Aug 25, 2013, at 07:36 PM, John Young wrote: > > Phil probably means the infrastructure of email is the vul not the > > crypto. Crypto alone is sterile, a boy in a bubble which requires > > life support which can be assaulted. > >I think Phil is referring to traffic analysis. We solved this problem >already somewhat with Mixmaster, but it's cumbersome to impossible to >use for everyday email. It's not just traffic analysis, though that's another layer of the problem. And it's not just the issue of PGP being hard to run on some phones, though that makes it a problem for users of those phones. Phil's not just a cryptographer; he's primarily a service provider here. If you assume that the NSA can come to you with a FISA court order overriding ECPA, saying "Give us every piece of information that anybody sends you, including your subscribers and outsiders who want to send email to them, any time any new bit of information arrives, Or Else!" then you can't run a "secure" email service that accepts unencrypted email, because what you have isn't secure against that threat model. If the NSA and their rubber-stamping buddies at FISA aren't stepping way over the bright shiny constitutionality line, you could run an email service that automatically PGP-encrypts any incoming message to a public key associated with the mailbox, and build a user interface for the mailbox client's device that's not totally annoying. The fact that Phil and Jon say they can't run a service implies that the threat model includes mail in transit, not just mail delivered to a mailbox. You might be able to run an email service that scans inbound email for an X-PGP-Encrypted: header, and if it sees "From:" or "Subject:" first, bounces the email with a 503 or 550: "Sorry, Encrypted Email Only, Get PGP at www.pgp.com", but that's really more annoying than just using Gmail with a user name pgp-only-johndoe43(a)gmail.com. An alternative threat model is that the NSA declares anybody sending encrypted mail to be a target (s/target/weasel-word-of-the-week/g), so any ISP that sends data to silentcircle.com has to allow the NSA to wiretap their connections, just in case they might be encrypted email. The effects are similar, though it wouldn't provide access to the contents of encrypted SMTP sessions; Phil and Jon might also be refusing to handle email because of this slightly less aggressive threat model. Bill Stewart

4 4

Re: [liberationtech] Why_can't_email_be_secure
by Bill Stewart 26 Aug '13

26 Aug '13

At 01:40 PM 8/25/2013, coderman wrote: >and to StealthMonger's point about latest generation mix networks for >best privacy, why not instead focus on building low latency protocols >that are resistant to traffic analysis and confirmation? Because "low latency protocols that are resistant to traffic analysis" is a really really hard problem. Even doing "high latency protocols that are resistant to traffic analysis" is a really hard problem. "Building" them is a mere application of sufficiently advanced technology, right? >make them datagram based; utilize user space stacks Datagrams don't give you any useful anonymity, because any decent ISP is going to block forged-source packets, but they do give you a bit more flexibility about timing, which is important for defending against traffic analysis. The standard warning about using them for an application is that it's extremely tempting to use them to reinvent TCP badly, because TCP really does a lot of things you want, and in a security context it's tempting to also reinvent TLS badly. Some other problems with them are that you need to get firewalls to allow them through, unless you disguise them as other protocols like the horribly evil things Dan Kaminsky regularly does to DNS, and if you don't disguise them then they stick out like a sore thumb on any IDS or netflow analyser. And if you're the only person using that protocol, you're not hiding from traffic analysis. It's a lot easier to hide if you implement your datagrams as http/https transactions of some kind, but building a bunch of relay nodes to pass those transactions along ends up reinventing Tor. Putting them in user space is just fine and mostly more portable. It's hard to get millisecond-level latency if you do that, but you can't hide from traffic analysis with latency that low anyway.

2 1

Re: Who bought off Zimmermann?
by Bill Stewart 26 Aug '13

26 Aug '13

At 10:45 PM 8/25/2013, Shawn K. Quinn wrote: >Though I think the following poster who >suggested scanning the email itself for the PGP identifier might be more >useful and less prone to being fooled by someone who just puts the >header in there without actually encrypting. Anybody who's putting in the header without doing the encryption is going out of their way to ask for trouble, and presumed to be doing it on purpose, whether for entrapment or denial of service or whatever. As long as you don't make it easy to do by accident, it's not a problem. >Also, headers don't have to >be in a specific order, it's possible that "From:" or "Subject:" >accidentally get moved ahead of "X-PGP-Encrypted:" by mistake and that >would result in a false bounce. The threat model I was worrying about was that if you get to From: or Subject:, and you're subject to an NSA Vacuum Cleaner Order, you've got potentially sensitive information about your users or their contacts that you could be forced to retain and turn over. You need to reject the message before you see that, which means checking the header keyword before you accept any characters past the :. And yeah, that means you could get false bounces, but hopefully anybody who's trying to hide their identity from the NSA will leave those headers out of the cleartext part of the message anyway. Ideally you don't even want the SMTP-level FROM keyword, but it's probably hard to get most MTAs not to send that one.

1 0

Re: [liberationtech] Why_can't_email_be_secure
by coderman 26 Aug '13

26 Aug '13

On Sun, Aug 25, 2013 at 12:26 PM, Ali-Reza Anghaie <ali(a)packetknife.com> wrote: > ... > And herein lies the problem - Silent Circle isn't talking to "us" - > they are talking to the other 99.99% of email users in the world. and to StealthMonger's point about latest generation mix networks for best privacy, why not instead focus on building low latency protocols that are resistant to traffic analysis and confirmation? make them datagram based; utilize user space stacks and latest research. solving the low latency datagram anonymity problem enables existing usable private communication with the additional benefit of endpoint and peer anonymity. i believe this possible to make useful, even if never infallible. certainly more possible than the odds of making truly scalable, available, and _usable_ mix mailer networks and clients for the masses. most important: make this low latency infrastructure usable and cross platform, so the implementations are easily adopted... like Napster and BitTorrent back in the day. ;)

2 1

Avaaz in "grave danger" due to GMail spam filters
by rysiek 26 Aug '13

26 Aug '13

OHAI, I happen to be on Avaaz's info distribution list, and I got an e-mail lately that Avaaz is in "grave danger" as GMail will now filter mailings like that out to a separate folder for similar spam-ish (yet not spam per se) mailings. So what they're asking people to do is to reply directly to that e-mail, so that GMail will note that Avaaz's mailings are not to be messed around with. Instead of telling people, you know, to decentralise and use other, smaller providers. I facepalmed so hard I could cry. It's Stockholm Syndrome if I ever saw one. "GMail fucks us in the arse, so let's ask them politely to use some lubricant". My question is: does *anybody* on this list have some kind of contact within Avaaz? I'd *love* to talk to them about it. It's simply disingenuous to do such a campaign and *not* at least signal "oh and by the way, had we all been still using different, dispersed, decentralised e-mail services we wouldn't get even close to having this problem". -- Pozdr rysiek

14 36