croikle

I'm aware of simple brute-force attacks on short key IDs [0], which are just the last 32 bits of the fingerprint (e.g. 438CF0E2). With significant effort, one might be able to extend that to 64 bits.

I'd be much more surprised by a full fingerprint match. Wouldn't that imply a SHA-1 collision?

[0] http://www.asheesh.org/note/debian/short-key-ids-are-bad-new...

I believe it's Certificate Transparency, a Google project for globally monitoring SSL certificates.

http://www.certificate-transparency.org/

Is there any protection from trolls sending mail to this address? Yes, one can roll back the change, but an automated attack would win.

Perhaps the address should be an unguessable <GUID>@ngrok.org instead? Or do you validate SPF and only accept mail from your ISP?

(Maybe you already have solutions; I just found it interesting to consider abuse of the system.)

Yeah, the way the rules work magnesium is a dead-end. You have to double-oxygen to get to silicon, and then it's smooth sailing. (Note that all implemented reactions are listed if you scroll down)

> For instance try finding out what stocks and weights make up the Russell 2000 index

This actually sounds like a fun little linear algebra problem.

Seems to work for me. I opened the Flash Player preference pane and discovered that it had already updated to 12.0.0.70.

So, I'm not sure about that one. Apparently s_client ignores the error and completes the connection because it's intended to be used for debugging.

> Currently the verify operation continues after errors so all the problems with a certificate chain can be seen. As a side effect the connection will never fail due to a server certificate verify failure.

https://www.openssl.org/docs/apps/s_client.html

https://www.mail-archive.com/openssl-users@openssl.org/msg71...

Yeah, I'm not sure. The linked diagram [1] shows them influencing routing, rather than some timing issue.

[1] https://www.documentcloud.org/documents/785152-166819124-mit...

Bufferbloat on the upstream pipe, if somebody is using your shared connection.

AMA: http://www.reddit.com/r/MMA/comments/13govr/hi_rmma_im_one_o...

You can find plenty of wikidrama at https://en.wikipedia.org/wiki/User_talk:Agent00f and https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment...

One license offered for Phil Rogaway's OCB block-cipher mode explicitly prohibits military use. (although, as I read it, the military could use still open source implementations under the other license)

http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm

Even disregarding Apple's control over the software, the system depends on Apple as a trusted key distributor. This is the vulnerability which the article is concerned with, as far as I can tell.

It's a cute idea, but you have 1/r^4 intensity scaling, which is prohibitive even at lunar distance. The lunar ranging experiments receive "one photon every few seconds" [1]. You could probably do better with bigger equipment, higher power, and perhaps an orbiting base station to skip the atmosphere, but the numbers are going to win before too long.

An active repeater would give you 1/r^2, though. For example, you could ping Voyager I for a 36-hour delay. However, that's likely not feasible at light-year distances, let alone the problem of getting the devices there. :)

[1] http://www.jpl.nasa.gov/news/news.php?feature=605

> Apple claims that even with access to the device, a nine digit passcode would take 2.5 years to brute force.

That's 2.5 iPhone-years of computation, though. A speedy desktop could be 10 times as fast, and that's before we get to GPUs or multiple machines.

Chrome's pinning is a definite upgrade, but it's more vulnerable than some people make it seem. In practice, a pin consists of a list of CA certificates which are allowed to sign for the given domain (the list is in [1]). This list can be surprisingly long: for example, the list for twitter.com contains 22 keys from 3 different CAs.

This means that, e.g., if you are "good friends" with Verisign, you can get them to issue a certificate for any Google property, and Chrome will happily accept it.

[1] https://src.chromium.org/viewvc/chrome/trunk/src/net/http/tr...

No. You cannot outsource your random number generation unless you have an ultimately trusted third party. The important thing is that nobody knows your random numbers. After all, random.org could be malicious or compromised, too.

In fact, even better: you can add forwarding to your existing connection. <newline>~C opens a command line, which accepts the following commands:

    ssh> help
    Commands:
      -L[bind_address:]port:host:hostport    Request local forward
      -R[bind_address:]port:host:hostport    Request remote forward
      -D[bind_address:]port                  Request dynamic forward
      -KR[bind_address:]port                 Cancel remote forward

(If you're not familiar with them, some of the other escape sequences are useful too. ~? lists them all.)

[EDIT] Apparently, if you have a recent enough version, you can add a forward to the master with `ssh -O forward ...` [1]

[1] http://serverfault.com/questions/237688/adding-port-forwardi...

You can skip the master and spawn a fresh connection for your tunnel using `-o ControlPath=none`.

Judging by [1], the latter.

1: http://identity.mozilla.com/post/56526022621/what-is-an-iden...

s/prevent/mildly discourage

To be fair, at 10 gigabits that buffer is only 12.5 ms, but given their dedication to latency I can see it being worth investigating.

This flight was a month ago, and was briefly discussed here [0]. Video of the winning flight is available [1].

[0] https://news.ycombinator.com/item?id=5884266

[1] https://www.youtube.com/watch?v=syJq10EQkog

This sort of thing is used, e.g. [0]. It collects entropy at a limited rate, though, so for demanding applications (SSL servers, say) you want dedicated hardware: [1], [2].

[0]: https://en.wikipedia.org/wiki/Hardware_random_number_generat...

[1]: https://en.wikipedia.org/wiki/RdRand

[2]: http://www.entropykey.co.uk/

Note that it's possible to convert your keys to use PBKDF2: http://martin.kleppmann.com/2013/05/24/improving-security-of...

Or perhaps the best move is to hide. With such a large range of time, almost any species you encounter will be either incredibly primitive (thus not so interesting, and not receptive to your signals), or tremendously advanced, and a serious existential threat. Faced with this choice, it's quite rational to avoid looking for the neighbors.

This doesn't really apply to the self-replication wave, but it is an argument against active SETI.

I'm a fan of Diceware. Strong entropy guarantees and memorable passwords.

Don't worry about it. Actually, you get meat & fur from that event, so it's not terrible.

Warning: while the first part of the game works fine in a touch-based interface, a later section requires a keyboard. You'll be annoyingly unable to proceed on a touchscreen.

> and I'm not entirely sure if those key-ID's are sufficiently unique and/or secure

They aren't: http://www.asheesh.org/note/debian/short-key-ids-are-bad-new...

There is some research in this area, e.g. http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf