bonzoesc

Modern symmetric ciphers solve the "you need to securely exchange as much key material as you wish to send data" using mathematical formulas to stretch key material. Asymmetric ciphers use mathematical formulas to fix "you need a secure way to exchange keys."

Unfortunately, the math can't be probably secure, only believed secure and proved insecure.

Comment · 13 years ago

I'm confused as to why you'd need a third-party for this.

The Authy app is better.

Look at the screenshots at https://itunes.apple.com/us/app/google-authenticator/id38849... . The buttons are ugly, labels are misaligned, and the colors are ghastly.

Re-ordering tokens in the Google Authenticator app is janky as hell too, and the only way you'll know if it's going to work is if the regular view switches to one with subtly different font sizes.

Authy's not without its rough edges, but it never looks that bad.

From down-thread, regarding Google Authenticator: e.g. setting up 2-factor with MS with the same email you use for Google will overwrite the Google one unless you rename it.

Authy does this correctly.

Comment · 13 years ago

Flat is in this year.

Comment · 13 years ago

Sterilize & release programs for feral cats work; the sterilized cats compete for the same resources as unsterilized ones, but are more effective and longer-lived because they don't have to support reproduction. This not only means that the sterilized cats won't reproduce, but the unsterilized ones will have a harder time, and reproduce less.

It works better than trapping & killing.

Comment · 13 years ago

"http://jessicahische.is/monkeyingaround" has got to be the best URL I've seen in a long time.

Comment · 13 years ago

It does a merge sort, and I can't see that you can opt out of it: https://github.com/basho/riak_kv/blob/master/src/sms.erl

2i doesn't use mapreduce in normal operation.

Comment · 13 years ago

Secondary Indexing Improvements: Query results are now sorted and paginated, offering developers much richer semantics

So the results can be sorted but are not stored in sorted order in the secondary indices?

Secondary indexes are stored sorted on disk, but segmented per vnode. Previously, they wouldn't be sorted before being returned to a client.

Suppose you're querying for "Bananas" through "Bavaria"; the node that contains "Bassoon" could return its first result before the node containing "Bananas" and "Barons", which would, in old Riak versions, result in out-of-order results.

Disclosure: I work at Basho, and have been working on riak-ruby-client updates to support the 2i improvements.