Freaky

Or the JIT. We're not all using MRI.

They'll be USB soon :P

For USB there's always a MU - very compact folded up: http://www.themu.co.uk/

Brute forcing a password hash is a lot different from being able to trivially extract it from memory long after it's been used.

People generally aren't carefully clearing passwords from memory after use, and ideally GC runs aren't happening all that often. "Exactly the right moment" could easily extend out to many minutes.

You can use client certificate for authentication using TLS. The main difficulty is how dire the UI experience is on the browser side - it's evidently little more than an afterthought for vendors.

Obsolete is not the same as insecure. But it is old, it does have its weaknesses, and there have been better options out there for a very long time. Why continue to use it? Is upgrading your crypto that difficult that you'd rather just leave it for another decade or two?

It also calls into question the nature of all the other crypto they're using - is that all >20 years old too? Still tuned for a world of 486's and 68040's?

Sure, but it's not exactly putting them in a good light is it? Dressing up obsolete stuff as state of the art "same as your bank uses", while either being unwilling or unable to migrate to something more era-appropriate.

Calls into question their competence, their honesty and their architecture all at once.

> I've used CrashPlan a lot and basically take it on faith that it's secure

They use Blowfish. Says it all really - their default encryption is a long-obsolete 64-bit block cipher you might have picked in 1999 because it was faster than 3DES.

I can only assume they do this because migrating would cost them money, and being able to advertise "448 bit encryption" actually sounds like a plus to most people and not the glaring red flag it actually is.

> it seems like their software is still first rate

What, like their backup client that can't actually do restores? It's still all "log in to our website and let us decrypt your data for you" :/

The Amiga game Alien Breed 3D came with this code booklet, printed in black-on-black: http://i.imgur.com/ok4mYSk.jpg http://i.imgur.com/Y9w0M7S.jpg

Looks like you're right: https://github.com/restic/restic/issues/21

And of course you can't do it after the fact because you can't turn off the crypto.

Gave it a quick go - plugged it into an existing Attic backup script so it scanned/excluded the same dirs. Result:

7.9MB Attic etc backup -> 22MB Restic backup.

43GB Attic homes backup -> 71GB Restic backup.

You typically don't get registered memory support on the basic single-socket Xeons. It's more a multi-socket thing.

Absolutely. Memory errors are insidious because they can look like just about anything - driver bugs, software bugs, disk errors, power issues, media blips, or even nothing at all, just some silent bit of data corruption you don't even notice. It's easy to dismiss the risk when you have no idea how big it is.

It's eye-opening once you've managed a few machines with ECC and seen first hand how common correction events are.

Linux is very conservative with how much entropy it credits to things like RDRAND since they can't be easily trusted. Looks like you get one extra bit per interrupt:

https://github.com/torvalds/linux/blob/master/drivers/char/r...

You'll note no other use of arch_get_random_* throws anything at credit_entropy_bits().

Linux 3.17 did bump up the assumed quality of virtio-rnd:

https://github.com/torvalds/linux/commit/34679ec7a0c45da8161...

Hard limit of 72, beyond which many implementations will silently truncate, and reduced entropy from each character beyond 55 bytes.

Probably a good idea to pre-hash. Or use scrypt.

He's questioning normalisation, not base. "Just over 2^30" is a bit more intuitive than "Just under ten times 2^27".

When I upgraded it gave me a page showing me the new defaults it was about to apply, and gave me the option to skip it and keep what I was using before.

Went with the latter option and indeed, it's still all MPC-HC, foobar2000 and Opera.

Maybe it's because I was upgrading from 8 you were upgrading from 7? I recall some changes to how defaults were handled between them.

No, like I said, it's exactly the same. If it decides it's a system drive, you can't unselect it, and it's very easy to make something a "system drive" when it's really entirely non-critical (a drive with some games on it, for example).

I at least found the one tiny non-critical service I had installed from my downloads drive - a PS3 controller driver. Ironically having removed that, the drive in question is now impossible to include in a backup. WTF.

It's all very frustrating when you just want to make an image of a single drive.

Yep, Control Panel\All Control Panel Items\Back up and Restore (Windows 7)

Exact same old craptastic System Image backup stuff. Still can't only backup my C drive, got to include my TB's of bulk data on non-system drives too, grr.

> openssl enc

Careful. Openssl enc is basically a poor toy example, it's not a robust authenticated encryption tool for real world use.

It explicitly doesn't support modern AEAD ciphers or even a simple MAC (so the ciphertext can be silently tampered with - note anyone who can do that can also replace your par2 files), and it doesn't use a robust key derivation algorithm for password use (single-round of a hash, basically, default MD5 - about as weak as it comes).

hpenc looks like a nice high performance modern alternative: https://github.com/vstakhov/hpenc

For my human-facing passphrases, I taught my password generator to scale automatically based on the size of the password space, the capabilities of an expected attacker (default: Snowdon's "assume 1 trillion/sec"), and the length of time for an attack (default: a decade). Keeps it clear how strong or weak what I'm using should be:

    -% mkpass -h
    Usage: mkpass [options]
        -a, --attacker [RATE]            Assume an attacker capable of RATE guesses/second (default: 1000000000)
        -t, --time [DAYS]                Resist an attack for up to this many days (default: 3652)
        -b, --bits [BITS]                Generate a password with this many bits of entropy (default automatic)
        -l, --length [LENGTH]            Make LENGTH word/char passwords (default automatic)
        -n, --number [NUM]               Make NUM passwords (default 1)
        -w, --wordlist [FILE | name]     Use file as wordlist (default comm3000 3esl)
        -v, --verbose

    -% mkpass -v
    Complexity 22088^5, 72 bits of entropy.  1811 centuries at 1000000000 guesses/sec
    messy photo groceries stoke horse

    -% mkpass -vb 100
    Complexity 22088^7, 101 bits of entropy.  88357157 million years at 1000000000 guesses/sec
    ungainly shopping mall dissociation turf across stridden microphone

    -% mkpass -vl3
    Complexity 22088^3, 43 bits of entropy.  2 hours at 1000000000 guesses/sec
    Weak passphrases: estimate 43 bits of entropy. 50+ recommended (length=5)
    terrace lower-class paneling

    -% mkpass -vw pin
    Complexity 10^18, 59 bits of entropy.  34 years at 1000000000 guesses/sec
    366565907478491511

    -% mkpass -vw alnum
    Complexity 62^10, 59 bits of entropy.  28 years at 1000000000 guesses/sec
    cTDng2KioE

50,000 requests aren't enough for the JIT to warm up?

Try grepping your lib directory sometime. In fact, let me do it for you, on a relatively clean install:

time, benchmark, irb, pry, rubygems, resolv, erb, rake, open-uri, debug, rack, cgi/util, optparse, getoptlong, bundler, activesupport, actionpack, activemodel, erubis, slim, haml, sass, sequel, roda, nokogiri, rugged, faraday, mime-types, thor, test-unit, tzinfo, mail, ffi

> had never been reported before, despite being largely the same for 9 years

I'll admit to encountering weird "er, why is that randomly nil" errors quite regularly with JRuby when load testing webservers, which, er, I've never reported. It's never been obvious where the fault was, really. And it always seemed unlikely to be your fault, tsk ;)

> It's better to avoid using closure state if you know it's going to be called across threads

Yeah. In this case it was a hash of name -> lambda pairs which boiled down to variations on:

    ->(obj) do
      case obj.bla
        when /foo(.*)/ then "FOO_#{$1.upcase}"
        when /bla(.*)/ then $1
      end
    end

Called in lots of tight loops from a pool of worker threads. I refactored it into something neater, but it still should have worked fine :)

They're what MRI calls "svars", or special variables. They're thread and scope-local, and regardless of your feelings towards them, they're still used all over the place, in old and new code alike.

The same bug still exists in JRuby 9000, and was in fact the first thing I ran into when trying it.

Considering threading is the main selling point, one of the commonest patterns of regexp use being completely and dangerously broken with them would have seemed like something of a showstopper.

Concurrent threads using magic regexp vars like $1 stomp all over each other, quite nasty: https://github.com/jruby/jruby/issues/3031

Stumbling over a serious race condition in the first 5 minutes of trying it with real code makes me a bit wary. All the performance in the world isn't much good if it's randomly wrong :/

At Newzbin we used them for reducing load on MySQL during Usenet header fetching - each new header would have the Message-ID put through a filtering service to check if it had already been inserted.

The service kept an array of 7 filters, rotated daily - the oldest would be cleared and reused for new items, giving us 6-7 days of history. Each individual header was low-value, and a few false positives every week wasn't a big deal - Usenet servers lost a lot more during their normal course of operation.

Calculator: http://hur.st/bloomfilter