This blog post is pretty disappointing. While true that AWS's egress can be costly, it is interesting that this article makes no mention of the fact that "non-partnership egress" on GCP is actually more expensive than AWS and that Azure is roughly on par. This article misses the opportunity to talk about cloud providers in a broad context and instead attempts to publicly shame AWS for not cutting a partner discount with them on egress for customers. Don't get me wrong, I'd love an egress discount, but this is "partner channel propaganda" masked as an AWS call-out.
This take is repeated a few times in this thread, but I'd counterpoint that AWS is the market leader, and Azure/GCP would be under much more competitive pressure to lower their bandwidth pricing if AWS brought theirs into line.
This article isn’t about reducing the cost of egress though, its about giving a discount when you peer with other partners. Its a very self serving argument.
oh. I love these questions. Handshake author here. Handshake provides a way for Alice and Bob to generate a large pool of one-time pre-shared keys as well as a set of one-time lookup hashes to go with these keys. Both the lookup hashes and the pre-shared keys are generated using separate KDF processes and the input bytes are destroyed upon generation. This pool of "lookup hashes" are unique to both Alice and Bob and can be used in any order. There is no further coordination of future key generation, so this is very much the "impractical One-Time Pad" pattern. In fact, there is no reason that a true XOR based OTP couldn't be implemented as a "strategy" for Handshake.
So, no ratchets, just a bunch of "dumb" one-time-use symmetric keys with a lookup table for each chat participant. The value prop here is that, for some reason, you suspect that Eve is capable of cracking assumptions of difficulty or implementations of PKI at a level in which you want a symmetric-only crypto alternative. This puts Handshake squarely in "cyber-punk vanity project".
Operationally, the biggest known risk with Handshake is device security. If Eve was able to get a hold of your device, she'd be able to decrypt all future messages related to that chat conversation (though she wouldn't be able to decrypt messages before interception, since keys used by both the sender and receiver are aggressively destroyed upon use).
Ah, thanks for the response! So the number of messages you can send is precisely the number of keys that you generate at the start? How many is that? This also probably means you don't support long-running (think multi-year) conversations or the ability to add/remove people to/from the group, is that right?
> So the number of messages you can send is precisely the number of keys that you generate at the start? How many is that?
Bingo. The demo only generates 10K keys per participant, but 100k keys in storage takes less than 200ms to generate and only uses 6MB of storage space. This will be user configurable per chat. It's important to note, each message burns two keys. The first key encrypts the message, the second key encrypts the reference to that message for the rendezvous point.
> This also probably means you don't support long-running (think multi-year) conversations or the ability to add/remove people to/from the group, is that right?
Correct. There are plenty of other tools that do a beautiful job of handling that. This is designed specifically to provide short-lived chats with specific guarantees. The handshake happens just once at chat creation and all participants must be present.
The mobile app has some early proof-of-concept drawings and code, but that part hasn't been built yet. Right now its just core library in go with a simplified CLI interface and the ability for the code to compile to gomobile. The plan is for the mobile app to be reactNative + go (gomobile) with the ability to compile and sideload on iOS and Android. I plan to submit to the app stores, but using that depends on your risk model.
yeah, the sleep difference is a big one, for sure. That one became a lot more evident in the recounting of the last year.
I hope this post didn’t come off as prescriptive. That wasn’t my goal. It is meant to be about my path down not tracking and the suprising joy that has come from a mix of ignorance and intuition. I enjoyed keeping track of PB/PRs, and I don’t blame anyone for wanting to keep those in their lives.
For me, this is more about living in the moment. Metrics, no matter how “real time” they feel are always ever so slightly a reflection on the past.
Thanks! We moved down here for the adventure of it, its been a rewarding experience for sure.
Yep, I work part time for a couple of clients. Its a weird mix of data pipelining, systems architecture, orchestration, and site reliability work. I wouldn't have guessed I'd be working on this type of stuff 5 years ago, but I really enjoy it.
And yeah, it's funny, I don't really participate in Hacker News or Reddit (except in rare occasions like this, when someone points out my post is on here. vanity, I guess?). I've never included social news aggregators in my mental model of social media... but now that I think about it I can't really exclude it either.
I'm going to have to think about how I feel about this.