rojoroboto

I bet that the author would really get a kick out of the T2 Tile Project.

The last time I used scuttlebutt was at chaos computer camp in 2019. It was neat and peculiar.

He was forced there by our government. He was trying to get to Ecuador and wasn't given passage.

this is my favorite comment.

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.

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.

> 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.

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).

for the mobile app, the plan is to use QR codes + cameras, but its just byte blobs, so other transmission methods could be used.

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.

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.

This is a fascinating question. I’ll have to think about that one and see if I can figure out the root of it.

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.

I’m fine. My daughter sleeps on her own through the night (sleep training. it works.) and wakes up around 7am. Almost always after we do.

If this is, in fact, a few weeks before a mental breakdown, it would be quite a suprise. I’ll be sure to keep you updated if it happens.

I've participated in career days before and it was a lot of fun. The big thing to remember is: keep things concrete. Use stories and visual aids with concrete examples.

To really keep their attention, a presentation or interactive booth that let's them participate could help here. For the sake of simplicity, imagine a mad-lib style story through problem solving that allowed them to put in funny words for nouns, verbs, and adjectives while you tell a story of solving a problem with programmatic thinking.

You'll be able to structure it the same, but the novelty of video games, memes, and music references that will get laughs and will keep them engaged.

This addresses the checkin aspect of killcord but it doesn't address the payload address broadcasting and decrytion key publication aspect of killcord.

I am in the early stages of building a "providers" abstraction for killcord so that backend, publisher, etc are plugable. Using this bitcoin pattern for check-ins could be really cool.

Right. The decryption keys aren't on the blockchain until they are "published". If all publishers are compromised or shut off before that happens, the killcord project has been terminated.

This is true.

I'm working with a friend who is a copy writer to help make the landing page clearer and more helpful.

The purpose of killcord + ethereum for public disclosures is that leaning on ethereum as an API backend ties itself to the fact that taking down the entire ethereum network is difficult and running your own backend resiliently is hard.

That being said, I'm working on the concept of "providers" so that storage, payload, and backend can be plugable and you'll be able to use whatever backend you are comfortable with.

neat. Yeah, I picked symmetric encryption for the payload due to its relative simplicity, speed, and resiliency.

Yes. In the current form, If someone gets the project owner config file they could continue to check-in indefinitely.

I've been toying with the idea of optionally encrypted the owner config with a passphrase to mitigate this. It would even be possible to have a secondary "duress password" that pretends to decrypt the config, but publishes instead.

This is left up to the killcord project owner to set the publisher threshold. If the project owner is concerned about congestion the owner should increase the time allotted to the threshold.

yep. this falls in line with my design thinking on this.

This is a valid concern and why I'd encourage running multiple instance (geographically distributed) of the publisher.

Solid feedback.

Killcord is designed to let the public know that a killcord project exists, where to find the encrypted payload, and how to check the status of the killcord project.

Unpublished secrets are currently stored on the owner and publisher project folders in clear text on a config file. This isn't meant to replace an HSM or secret manager, by any means. Though I've got some ideas on how to incorporate systems like Vault, Chamber, or other secret stores in the future.

It is also, indeed, early alpha and dealing with secret management for the owner and publisher are absolutely top of mind.

These are valid points and anyone thinking about using killcord should be aware of these.

As for the second attack vector, the publisher is built with idempotence, so it is important that a killcord owner configures n-number of publishers in geographically diverse areas to mitigate the false negative attack vector.

Killcord treats ethereum as a project backend API. The smart contract is pretty simple in construction by design. Writes are restricted to one of two accounts (the owner account and the publisher account) and the publisher account is further restricted to only allow writes to the publishedKey variable in the contract. Reads are open to the public.

As stated in other responses, the decryption key is stored own trusted systems that run the owner or publisher killcord projects.

As for attacking the system this is something to think about. So why did I choose Ethereum for this?

Why Ethereum - The contract code (backend API) and variable state are written to the block chain, so the availability are dictated by the network itself which is made of around 20K nodes (give or take). Of course, as others have mentioned the other aspect of this is internet access for the publisher and project owner.

For the publisher, this can be accommodated by running the publisher in a geographically distributed set of trusted systems. What do I mean by trusted systems? These are systems that meet your risk profile. The code can run on AWS Lambda in multiple regions, or on a raspberry pi, or in a datacenter in iceland, the more, the merrier.

For the owner... If you are cut off from checking in, the system assumes something bad is afoot. This is why its important that anything put in killcord is something you really want to publicly disclose. Killcord should really only be a system that runs on your behalf in the case that you go MIA and you feel that is a threat to the data being otherwise released.

Hope this helps clear things up a bit?

Hey Gang. Author of killcord here. I'm honored and humbled this was submitted to HN and I'll be reading through the comments to answer questions and respond to feedback. I started this project after a thought experiment in using newer decentralized tech for internet activism.