/tech/ - Technology

Hiding most of the tripcode creates the issue of visual collisions. People aren't going to check the full tripcode. 

Being secure should be the default, unavoidable, easy option, not something that requires understanding of hashing and going out of your way to check it.

>>10534
What I wanted to do is strike a balance between saving space (64 characters is long) and still being secure. For example, this site's software (jschan) handles its secure tripcodes in a way that I don't personally agree with. Here's what it does.
-Hashes the password with SHA-256 with a secret salt
-Encodes the output in base64
-Destructively truncates to 10 characters

I wanted to:
-Use SHA-384 because it's perfect for base64 encoding (and it's mathematically stronger)
-NON-DESTRUCTIVELY truncate to 16 characters (which is quite a bit higher than 10, quite less likely to cause a collision) and allow the entire 64 character trip to be viewed on click or hover.

If you know how to do the math (I sure don't) how mathematically likely do you think it would be to cause a collision if truncated to 16 characters? I like the idea of striking a balance between verifiable security and reasonable length tripcodes.

>>10535
No idea my dude.

Here's an implementation of your tripcode algorithm:
language: c
#include <stdio.h>
#include <string.h>

#include <openssl/evp.h>
#include <openssl/sha.h>

/* Anon's tripcode algorithm.
 * Compile command: cc `pkg-config --cflags --libs libcrypto` tripcode-gen.c
 */
int
main(int argc, char **argv)
{
	char digest[SHA384_DIGEST_LENGTH];
	/*
	 * sizeof(digest) = how many bytes of hash
	 * b64 encoding is 4/3rds of the size of the input.
	 * + 1 for terminator.
	 */
	char tripcode[sizeof(digest) * 4 / 3 + 1];

	if (argc != 2) {
		fputs("Pass exactly one argument, your tripcode password\n",
		    stderr);
		exit(1);
	}

	SHA384(argv[1], strlen(argv[1]), digest);
	EVP_EncodeBlock(tripcode, digest, sizeof(digest));

	printf(
	    "Short tripcode: Anonymous !%1$.16s\n"
	    "Long tripcode : Anonymous !%1$s\n", tripcode);
}It depends on LibreSSL or OpenSSL as the comment above main() says.

In use:
$ cc -O3 pkg-config --cflags --libs libcrypto -o tripcode-gen tripcode-gen.c
$ ./tripcode-gen test
Short tripcode: Anonymous !doQSMg97CqWBL85C
Long tripcode : Anonymous !doQSMg97CqWBL85CjcRwazyuUOAqZMqhangiSb/o78S37xzLEmJV0ZYEff7fF6Cp

I_forgot_how_to_program_it.jpg
[Hide] (244.7KB, 1280x960)

Salting also makes it impossible to bruteforce tripcodes locally. An attacker has to steal the salt from you without you finding out or spam your imageboard.

>>10537
Thanks anon. If you have any ideas for improvement, or alternative methods to do a more modern tripcode implementation, your thoughts are welcome.

>>10538
Or bruteforce the salt too, which means even more complexity. An incredibly complex password is already going to be very difficult to bruteforce anyway. Pair that with a slow algorithm like bcrypt, and you're in hell. I suggested SHA-384 instead of bcrypt paradoxically because it is fast: I do think generation of vanity hashes is important for adoption (tripcode, onion v3, etc).

>>10540
There are those password expansion algorithms I guess. It's just that people will use 3 letter passwords and the like,  3 lowercase letters is 26^3 or 17576, this is trivial to bruteforce locally, but it'll be obvious if someone spams you with up to 17576 posts to bruteforce a tripcode.

>>10541
This will always be a problem. I'm using a tripcode that's just #a, the system is only as secure as you are. However, even worse, the current tripcode system is limited to 8 characters. try it for yourself, try a tripcode with 8 characters like #password and then try #password1 and you will get the same output. At least with a revamp, you have a higher potential for security, you can use a much longer passphrase and you could get a lot of entropy with something like unicode. Make your tripcode password have a string of emoji cancer to keep the glowniggers from impersonating you.

>>10543
>This will always be a problem.
Actually you could just set a minimum length of 16 or something.

>>10544
16 is too long. I did some calculations when I wrote a password generator and 10 characters of uppercase+lowercase+numbers would already require a supercomputer costing double the most expensive supercomputer ever built to crack it in 1 year on CPUs alone, probably an order of magnitude or 2 more once you factor in the other parts of the computer, a facility to house it computer, staff to build it, the electricity costs, etc.
If you use the base64 alphabet for the password, I can't be assed to redo the calculations, but even 8 chars should be plenty.

But the problem is local (cracking a hash in your own machine) vs remote (spamming a service until it gives you what you want) bruteforcing. No point in building a billionaire password cracker if you can't bruteforce locally. This is what salting solves.

Also, you can pick the length of the hash with BLAKE2. 24 bytes means 192 bits of hash, 32 bytes base64 encoding. No idea how many bits are needed for security and if you can improve security by using a password stretching algorithm to slow down hashing.

Also, if only display length matters, you could come up with an UTF-8 alphabet as anon already mentioned. Just adding all the variations of accentuated Latin letters will easily give you an encoding that manages 8 bits per display column. We could possibly manage even more.

>>10545
Well the first post in this thread was of the opinion that you can't be too secure. I suppose the min length is up for debate. I just chose something that sounds reasonable and somewhat future-proof. I don't personally know how long it would take to bruteforce this but I suppose I'll just believe you that 10 is seriously going to be that difficult for SHA-384.
>This is what salting solves.
My earlier point is that a weak salt could be bruteforced as well. If your password is "password" and your salt is "salt" I wouldn't say this is secure, no matter the fact that it's salted.
>Also, you can pick the length of the hash with BLAKE2
I've forgotten about BLAKE, the BLAKE stuff has some very interesting properties I've wanted to look into.
>No idea how many bits are needed for security
Neither do I, I just chose SHA-384 because I am sure that 384 bits is enough to be secure and probably very well future-proofed and it works perfectly for base64 encoding the output.
>10546
Yeah, you could make some sort of base 128 encoding or something, then you could use SHA-224 and you'd have a 32 character tripcode.
The problem is finding another 64 "desirable" characters or something that would work easily in this scenario. Base64 is a well-known and easy to implement standard for developers, as is SHA. Coming up with your own text encoding standard is an option, however, I think shortening length by using BLAKE sounds like a better idea. Also SHA-3 apparently has arbitrary digest sizes like BLAKE so that could be nice.

>>10546
Somehow fumbled my keyboard and deleted a > and fucked my quote in post above.

Honestly maybe the answer is figuring out what digest size is considered "secure enough" for SHA-3. If you want a 10 character tripcode, you want SHA-3 60 bit. Not good enough? 72 bit for a 12 character trip. 20 character tripcode? 120 bit. This is for base64 encoding of course, which would make it look very much like a standard tripcode.

Apparently SHA-3 doesn't actually support variable length. The underlying Keccak algorithm does, but the SHA-3 standard doesn't use it. A Keccak-based standard with support for variable-width output would be SHAKE. But does anything even use it?

Also, with passwords you have the problem that the input of the hash algorithm is (most likely) shorter than the output which is apparently a bad thing, so you need to use something like Argon2 to begin with.

>>10551
>Apparently SHA-3 doesn't actually support variable length. The underlying Keccak algorithm does, but the SHA-3 standard doesn't use it.
Arbitrary digest length is apparently supported by SHAKE128 and SHAKE256 which are definitely a part of the SHA-3 standard. From what I'm reading, I don't see why you couldn't set it to 72 bits for a 12 character tripcode.
A 10 character tripcode in base64 would be 1.1 quintillion possible trips. 12 character tripcode would be 4.7 sextillion. It's sounding good to me in theory, but I'm also interested in what others have to say. By this point I think I'm entirely reconsidering my SHA-384 idea.

>>10552
>Also, with passwords you have the problem that the input of the hash algorithm is (most likely) shorter than the output which is apparently a bad thing
Also I should mention that for a 12 character tripcode, the output would be 9 bytes, so a typical password that would use ASCII letters, numbers, and symbols could very easily be 9 characters or more.

I guess let me get a basic "white paper" going:
SHA-3 SHAKE128 or SHAKE256 (would want to read the advantages and disadvantages and figure out how they would or would not affect tripcodes)
Set the minimum password length to 9
The digest would be 9 bytes, which could be perfectly represented in base64 with a 12 character tripcode.

How does this sound?

Or Argon2id with 128-bit hash + UTF-8-based base-256 encoding for a 16 byte tripcode.

>>10556
>base-256
This?
https://crates.io/crates/base256

Also, salting is per-password, we're thinking about peppering which is a shared salt for all passwords in a service. Salting means the tripcode has to be stored in the server. It's useful for services with registration, but that's not tripcodes.

And the current tripcode algorithm seems like the password-hashing algorithm from Version 7 AT&T Unix.

>>10557
No. I'm thinking about picking 256 UTF-8 characters that are 1 column wide. base-32 uses a 32 character alphabet to encode bytes, base-64 uses 64, base-256 would use 256. That means you have 1 display column per byte encoded, so you can have a 16 column tripcode that encodes a 128-bit hash.

>>10558
>Also, salting is per-password, we're thinking about peppering which is a shared salt for all passwords in a service.
Seems to be a common misnomer in IB development then.
>I'm thinking about picking 256 UTF-8 characters that are 1 column wide.
Yeah I kinda assumed.
I personally think this is a bad idea because:
-It's harder to implement your own encoding standard than to just use a common and ubiquitous one like base64.
-You dilute the pool of desirable characters (letters) with a lot of cruft that's going to be hard to get out of. Everyone generating vanity trips is looking for letters. Currently tripcodes only have 12 cruft characters: 0-9 and 2 symbol/punctuation characters. Tripcodes will probably be messy and full of unmemorable characters, and thus the entire tripcode will be largely unmemorable. !Penis6yoHc is memorable. !ê😭漢@лáф⫤반ㄴAδ✨æλ8 isn't memorable at all.
-Base64 is already extremely similar to the current encoding, keeping the encoding familiar.

>>10559
Honestly, 0-9 don't even have to be cruft. 60Niggers would be a good trip.

>>10559
It's trivial to implement base64 or something like base64 with more characters, including utf-8 characters.
You just create an array of pointers to char with 256 elements. The pointers to char are C strings with one utf-8 character per string. You use each byte of the binary representation of the tripcode as an index into the array to get one base-256 digit.

Also, the current alphabet doesn't even cover all of real world English:
Mötorhead
Nigger-hater
Pokémon

ALSO, it appears tripcodes either have to be very long like tor addresses or generating a vanity one is unviable because a password-hashing function that operates at at 1 password per second but creates secure, short tripcodes isn't viable for generating vanity tripcodes.

Oh and keep in mind hardware that can do a trillion sha2 hashes per second exists so you NEED some sort password hash function or any tripcode made with a password created by a human can be broken in a second.

Although no such hardware that I know of exists for blake2 or sha3, that'd be security through obscurity.

Peppering would solve this. But then you can't create vanity tripcodes because users won't have access to the pepper.


>>10533 (OP) 

Motorhead, Niggerhater, and Pokemon are probably fine for most but if you think you can fill 256 spots with good characters and not have a lot of cruft, I would be surprised. Once you run out of vowel accents and a couple other characters, you're going to be stuck trying to find 150+ symbols.
>ALSO, it appears tripcodes either have to be very long like tor addresses or generating a vanity one is unviable because a password-hashing function that operates at at 1 password per second but creates secure, short tripcodes isn't viable for generating vanity tripcodes.
No idea what you're talking about, tons of people have vanity tripcodes that were at least somewhat reasonably secure but are progressively becoming less so.

>>10561
Forgot to tag your post in the previous post
>>10562
>Oh and keep in mind hardware that can do a trillion sha2 hashes per second
Source? There's ASICs for blowing through SHA2?
>Although no such hardware that I know of exists for blake2 or sha3, that'd be security through obscurity.
Wouldn't really be any different if there's no hardware to do it for DES either.

>>10564
https://www.asicminervalue.com/
Apparently the "Bitmain Antminer S19 XP Hyd" can do 255 trillion sha256 hashes per second

>>10565
Got any figures for what a modern but mid-tier GPU can do to something like bcrypt? I may look to see if there are any ASICs for bcrypt. SHA3 may be a poor bet.

>>10566
bcrypt is a password hashing algorithm, you can just stretch it until it takes however long you want.

lmao
https://security.stackexchange.com/questions/139721/estimate-the-time-to-crack-passwords-using-bcrypt

You're basically looking at:

>Option 1
Password hashing algorithm with original encoding for secure and short enough tripcodes, but no vanity tripcodes because they'd be too slow to generate and users won't have access to the pepper anyway.

>Option 2
Use any hash algorithm, enforce minimum password length (and use an absurdly long one), don't pepper so users can generate vanity tripcodes, don't truncate or the hash algorithm could become the weak link in bruteforcing. Tripcodes would be extremely long and secure as long as the password is secure.

>Option 3
Continue using the current scheme which has a comically small password length and I'm pretty sure I can write a C program that cracks it in a reasonable amount of time.

>>10568
BTW, OpenBSD uses bcrypt and upon installation it benchmarks bcrypt and sets the parameters such that it takes 1 second to hash a password on the machine used for installation.

Also, I wrote a program that makes the correct horse battery staple scheme and ported it to everything, I wonder if I should dox myself by posting it.

What about SHA-3 with more iterations/rounds?

>>10570
That's basically a shitty password hashing algorithm.

Also, you could use the username as the salt for the tripcode and use a password hashing algorithm. Then tripcodes are tied to names and you don't have to generate vanity tripcodes, and then the imageboard is free to use peppering without breaking vanity tripcodes. Of course, that doesn't have the fun of generating a vanity tripcode.

thought.gif
[Hide] (122.7KB, 500x281)

>>10571
>Then tripcodes are tied to names
Mite b cool, mite b kinda ghey tho.
>Then tripcodes are tied to names and you don't have to generate vanity tripcodes
You should still be able to make a vanity trip, just give the hashing tool the salt (name) you plan on using, no?

>>10571
>That's basically a shitty password hashing algorithm.
Also shitty is my favorite kind of password hashing algorithm.
I think I would make the rounds high enough to where it's a lot slower than DES (hardware is really starting to power through the old tripcode standard) but still just fast enough to get some funny 4-5 character tripcodes like "fuck" or "penis" on modern hardware, just like this was possible but not completely easy like 15+ years ago for DES.

>>10572
The problem is that you need a fast hash to generate vanity tripcodes.
You're not going to manage to do that at 1 hash per second with a password hashing algorithm.

Also, you can see how many sha256 hashes you can do in 1 CPU core per second by running openssl speed sha256 on the command line. You need LibreSSL or OpenSSL installed of course.

>>10574
>The problem is that you need a fast hash to generate vanity tripcodes.
Yep. Realistically you need something not too fast (SHA2 on an ASIC) but not too slow (bcrypt). I think the perfect balance™ is going to be trying to get things to where they were with DES 15-20 years ago. Basically, with modern decent hardware (mid-tier) see how many hashes/second you can do and then add rounds for however many times slower you need it to be, in order to get it down to the maybe 10 million or so hashes/second that you could probably expect back in the day with DES tripcoding. In the future as hardware gets better and improvements to the tripcoding utility are (possibly) made, more impressive vanity passwords will be gotten (7 characters, 8 characters, 9 characters) out of a total 12, and then once you start approaching really high hash rates and you start closing in on 10 and 11 characters being possible with enough time, it may be time to update again. By that time, there will surely be much newer hashing algorithms that you'd want to switch to anyway (just like how we really need to drop DES for tripcodes by this point).

>>10576
*more impressive vanity tripcodes will be gotten

Let me get my thoughts down:
It should have enough rounds to make cracking someone's entire 12 character tripcode basically impossible, however 4-6 characters should still be doable in order for it to be fun (and half of the appeal of tripcodes is that tripcoding is an enjoyable).
A low end machine should be able to get 4 chars like !Fuck8fGZ1+9a
A mid tier machine should be able to get 5 chars like !Penis6yoHc/V
A high end machine should be able to get 6 chars like !Faggot+iz50p

But nobody should be able to get all 12 of those exact characters, making impersonation basically impossible (for the time being). Basically, the number of iterations should be scaled in a way where you get a period of a decade or more of vanity with reasonable assurance that your exact trip won't be matched.

>cross site tripcodes
what the fuck wiggery am i reading
of course a webshitter would choose to rely on this bullshit when they could literally just PGP the message (inb4 pgp bad yeah i know it is its you retarded wiggoids who made this a thing)

>>10590
Authentication != Signing

>>10590
Take your meds

Thanks for the enjoyable cryptography thread, when everyone pools together to discuss things in good faith, best practices and solutions can be found. Really great discussion.

>>10595
Signing does provide authentication. Just post a public key in the first message signed, then sign subsequent messages (cross-site). The server can even detect this and add the fingerprint as tripcode.