And you are here why?

/via https://bit.ly/2HKytRW If you have encrypted data up there in the cloud (•) you’ve probably run across  key rotation . It’s good practice —  very  good practice — and exists for some fairly straightforward reasons • Encryption stales .  Sometimes it’s just a matter of time (DES was awesome in 1977. Now, not so much). So if your encryption algorithm can be broken in  N  years, you probably want to rotate it in some period smaller than  N , no? And yeah,  N  isn’t necessarily “ heat death of the universe ” because you’re using 4096-bit keys. Things change — key leaks, quantum encryption,  NSA loopholes , whatever. The safe thing to do is just rotate your  signing key  —   and, potentially, the algorithm too !— every so often (••) • Keys Leak . It happens, and for a host of reasons, ranging from “ whyTF did you write it down on a Post-it? ” to state-actors. In either case, keys do leak. The safe thing to do is rotate yo...

So you’ve got a bunch of encrypted data. It’s safe, right? After all, it’s   encrypted , which means that nobody can get at it, right?   Right ? The answer to that is, very definitely, “M aybe, maybe not, couldn’t say for sure ”. The thing is, there are so many contributing factors to whether your data is safe. Bad Keys It doesn’t really matter how good your system is, if your password is “ password1! ” or “ admin ”, or something else on   this list of worst passwords of 2017 . Or, heck,   this list of the 10,000 most-used passwords from hacked password lists . Leaky Keys Even if you’re awesome, and have special super-complicated keys like “ correct horse battery staple ”, it doesn’t particularly help if you,   write it on a post-it . Maybe you’re better than that (please be!) and actually store it somewhere safe. It   still   might get hacked, and lords, if it does, it can be bad. Just ask   the fine folks at Lockheed Martin who got naile...

/via /via   http://speakgeek.isovitis.com/ Matthew Green has a nice writeup   on the whole   MedSec / St. Jude entertainment , specifically, on the underlying vulnerabilities that were the proximate cause for the whole (admittedly serious!) kerfuffle. It’s worth reading   the whole thing   in full, but one particularly egregious part is worth explicating, the role of   security through obscurity. ( Note : If you ever,   ever, EVER , think it’s a good idea, go take a nap ) I’ll just copy the relevant part below — it says everything that needs to be said… Programmer commands are authenticated through the inclusion of a three-byte (24 bit) “authentication tag” that must be present and correct within each command message received by the implantable device. If this tag is not correct, the device will refuse to accept the command. To our surprise, SJM does not appear to use a standard cryptographic function to compute this tag.   Instead, ...

Say you want to set a canary trap (°°) in your #SecretSauceDocument. You could embed a bunch-a “invisible unicode” like zero width spaces, confusables (different versions of “l”, “a” etc) and track them. Or, you can use #steganos (°°°) a small library of tricks — called branchpoints — that swap out • single quotes for doubles, and vice-versa • words for numbers (ten vs 10) • contractions (won’t vs will not) and so on. With the above, you identify the specific version of the original document based, and hence the leaker 🙌 Adding these fingerprints to an immutable store for auditability and verifiability (maybe on some verification oriented  #blockchain  like  #Factom ) would be both awesome — and, frankly, somewhat frightening 😱 (°) There is also a unicode version available, but that’s less fun 😇 (°°) Canary Trap —  https://en.m.wikipedia.org/wiki/Canary_trap (°°°) steganos —  https://github.com/fastforwardlabs/steganos

From the README —  https://github.com/google/crunchy “CrunchyCrypt is an open-source collection of cryptography APIs, safe and easy-to-use wrappings of lower-level crypto libraries such as boringssl [and] is designed to be extendable to both bleeding-edge and legacy cryptography.” “CrunchyCrypt has a built-in key versioning protocol, where [payloads are optionally] prefixed with a few bytes of key versioning information. This allows project owners to gracefully rotate new crunchy keys while maintaining backwards compatibility with old keys, even while switching the underlying algorithm.” The key (lol) here is that the use cases are, primarily, safety and ease-of-use. Which translates to ‘this is not a full on openssl/boringssl replacement” Also, in case you are wondering, this is a replacement for   keyczar . From   https://github.com/google/keyczar/issues/213 “Our internal version of keyczar is being rewritten as Crunchy Crypt … One goal of CrunchyCrypt is make...

The Extended Random extension to TLS — proposed by the NSA, and implemented by RSA —  by itself does not introduce any cryptographic vulnerabilities. All it does is increase the amount of random data (“nonces”) used in a TLS protocol connection… The only thing that’s interesting about Extended Random is what happens when that random data is generated using the Dual EC algorithm. Specifically, this extra data acts as “rocket fuel”, significantly increasing the efficiency of exploiting the Dual EC backdoor to decrypt TLS connections. —   https://goo.gl/Yg1yEY As always, remember 1) Crypto is   hard , don’t roll your own. 3) GOTO -1-

There is a nice writeup on this at Lawfare .  (TL;DR -  holding on to keys in a safe way such that 3rd parties can also access them repeatedly without high potential for catastrophic loss is impossibly hard) ...Apple’s design intentionally solved the problems that come from exceptional access schemes by removing itself from the equation. Rather than providing an exceptional access solution, Apple took the radical step of destroying those keys in order to have an acceptable level of protection.   [To] turn Apple’s Cloud Key Vault into an exceptional access mechanism....Apple would have to replace the HSM with one that accepts an additional message from Apple or the FBI—or an agency from any of the 100+ countries where Apple sells iPhones—saying “OK, decrypt,” as well as the user’s password. In order to do this securely, these messages would have to be cryptographically signed with a second set of keys, which would then have to be used as often as law enforcement ac...