Codefag here. I am interested in writing tools to make baking easier, ensure dough integrity, allow bakers to identify each other, coordinate handoff, ease notable collection, and perhaps set up a side-channel for meta-level discussion (could be a simple as integrating a thread on /comms/ on the same page as an ongoing bread).

I am slow and easily overwhelmed, but I can write good code (in the past I contributed the Nope button and a standalone post counter).

I've got some ideas on the topics I listed, but I will get lost in the weeds if I do it blindly, so I'm asking here for input on what bakers think would help the most.

>>2803

Thank you for the input!

It is clear that bakers must remain free to adopt or reject any proposed tool or practice. I'll keep that requirement in mind.

Pastebin account handles are not a bad method of identification, but it's a centralized approach, putting some amount of trust in pastebin.

Cryptographic signatures offer a decentralized approach to identify bakers, using the public part of key pairs that each baker could generate.

Including a signature of the dough's hash at the start of the bread is a no-brainer.

Authentication while discussing handoff is more interesting. To avoid replay attacks (re-using a previously posted message), a "nonce", a chunk of data that can't be guessed ahead of time, is needed. This chunk of data would be incorporated in signed messages used by bakers to indicate their interest in taking over.

A hash of the dough (or perhaps of the baker's posts prior to and including the dough) would serve well as a nonce, putting no requirement on the previous baker.

Does that make sense? It seems like a simple enough tool to write.

>>2805

I am considering writing a script that (1) adds a button to the reply form to append a signed message (indicating, for example, intent to take over), and (2) finds and verifies signed messages in posts, indicating "good signature from xxx" where "xxx" is the public key identifying the new baker (the key could be translated to an alias with a configurable directory).

The tool would also include simple keypair management (generation, backup, restore).

This tool could be made generic, allowing arbitrary signed messages in posts.

>>2807

Manual test post to see how it looks, then I'll write the verifier:

BEGIN SIG 1541282002261 d5I6ywXc/NVDkTtY/YXtst1xIlzrADT9UZWhI1vFb7Q=

Test signed message

END SIG 3vWfGCjGR2UlsgGVigEiDwg36M+zYbB0WI/p0+9/B++mvptSQ0b3de7BQRtXon2nmLhmdixcRmUbg8bNmsXYDA==

>>2808

BEGIN SIG 1541288461753 d5I6ywXc/NVDkTtY/YXtst1xIlzrADT9UZWhI1vFb7Q=

Erm, let's say the previous message was to test a bad signature.

This one should be good

END SIG wPeqymxbAI1/TJVbJhar8LHJGfT+xJF2mQpCZsjWec25hazXXNjKZnySVdhmaRLN7KAweUkcMI/hVPpV4mSsDQ==

>>2808

I messed up both tests. I've fixed the bugs, verification works. I will do another test once I've added the a posting interface.

>>2810

>is your basic goal to give the BAKERS a 'signature' that cannot be spoofed or imitated?

I think I fail to grasp the implicit content of your question. Can you voice your concern explicity?

A copy of a signed message from a past thread or another board will not pass verification. The signature is applied to the text between the markers, plus a timestamp (included in clear for checking) and a hash of the text of the original post (along with the board name, and thread ID). As a result, any alteration of the OP invalidates all existing signatures in the thread.

Because signatures are tied to a thread, the tool can (and will) detect signed messages copied verbatim in the same thread, and only mark the first one as valid. It will all be documented, and if any part of it is stupid I will gladly fix it.

This tool could end up being worthless for reasons I don't see yet, and that's fine. In any event I expect some to claim the code is malicious and should not be used by anyone. My 11 lines "Nope" script faced that, some said it was storing the gore images on your computer, when it's only storing the MD5 hashes. I'm sure some of it is due to genuine misunderstanding.

>>2812

BEGIN SIG 1541337393508 doo0mL2ZdkEHV/u1pz226baPDVwqidv7xhI6ksXF/58=

First hastily cobbled up release here:

https://pastebin.com/eqZMJFY4

END SIG IJpUq6Ojs2f7y30Om4CRMOW8K7jcKYERGreKc/veM1ighh1X4Hz6Ukkd0YE8VMmVybpRikVgGT0TCjvO4W60AQ==

Consider it a developer release. The script is incomplete, the crypto part is done by TweetNaCl.js and it needs to be included separately (which is unpleasant). Perhaps it's possible to reach out to CM to get tweetnacl.js.org whitelisted in the CSP, or better host a copy on 8ch servers.

There are several issues (main one is the Sign button only works in the top box, not in the detached quick post box) but I want this out there now. I expect 8chan formatting to cause issues (some sigs will fail to verify) even though most of the code attempts to deal with that.

Obligatory warning: do not use a script that you do not understand.

Let's see how this goes…

>>2814

(pic related) is how a good signature looks.

>>2816

>please tell me how this will help BAKERS

I asked here what would help bakers.

You indicated handoff coordination could be improved.

I wrote a tool that would allow bakers to identify themselves (while remaining anonymous) when they volunteer to take over, without BV/BO having to confirm.

Now you ask me how this will help bakers.

>>2818

The use case I see is that a potential baker would sign his in-thread offer to bake. This allows the current baker to tell (reliably) if the offer comes from a know baker.

>>2820

How do you know a message with tripcode !!mG7VJxZNCI is from Q?

Same here. There is information in the fact that an offer is signed with a public key you've seen before. What you do with that information is up to you. How you collect public keys is up to you (the tool could help build a directory, but each anon would have their own directory).

>>2822

>because the site admin, Ron aka CodeMonkey aka CM says so.

True. Tripcodes are generated server-side and CM can intercept passwords. But this is his site, we all trust him implicitly.

>who certifies that an anon is a 'known baker'

A public key with an established history of past good bakes stands on its own. Of course private keys can be stolen, but it isn't easy. I think it's pretty safe if the lack of technical efforts to break Q's tripcodes means anything (you can tell I'm having a bit of fun with those).

Making the tool easy to install and easy to use will take efforts, you're right. There's also establishing trust that the code does what it advertises and no more.

I'll keep working on it.

>>2824

"Baker Prestige" is harsh but it gets the point across. Anonymity is a good deterrent against paytriots.

>trivial

Indeed and it makes me wonder why Q's unsecure trips were not broken sooner. I estimate the capability to brute-force an unsecure trip in 24 hours costs $10,000 in hardware.

I also wonder why Q hasn't used a vanity tripcode so far. A clean WWG1WGA would look awesome and demonstrate serious computational power. Why not?

>not true

CM can just add code in post.php to log the Name field, around the line quoted below. The trip is computed server-side, the password is sent in the clear (though securely over https).

$trip = generate_tripcode($post['name']);

Crypto signatures with my tool are computed in the browser, so they are a little better in this respect. They would not necessarily be safe to use on a hostile platform.

>>2829

After more observation and thinking, I doubt that the ability to sign stuff would benefit bakers/qresearch. A mechanism that can be used to exclude subversive bakers can also be used to install subversive bakers exclusively.

The baking process seems robust enough as it is, even with a compromised BO. Critical thinking on the part of each anon is necessary, and any mechanism that supports the illusion of the contrary seems harmful.