/tech/ - Technology★

my dick

>>985215 (OP)

>Most secure cipher closest to the plaintext, weakest cipher at the outer layer.

Why? Back in the truecrytp days, there was the option to do AES then Twofish then SERPENT. Not the other way around.

>>985248

I guess you are right.

https://superuser.com/a/323957

> because you want the outermost encryption (AES will be the first layer they need to break) to be the most standard in the industry. That one is the most tried and true and the most tested of all of them.

> so they do all this work to break the AES, only to find that Twofish stands in their way now. And then again after Twofish they run into Serpent, which is the biggest beast of them all (even though it is less used / tested than AES, it still has a much higher security margin than AES)

Bonus Question:

NTRU or SIDH? And which one can be easily implemented (or even golfed) in Python/JS/Go?

Question about hand ciphers and deck ciphers:

Is this good for a post-apocalyptic world?

https://github.com/fruiz500/ChaosFromOrder (lots of fun hand ciphers)

https://aarontoponce.org/wiki/card-ciphers (all the card ciphers)

https://eprint.iacr.org/2017/339 (LC4 tile cipher)

https://github.com/pvial00/RedDye and https://github.com/pvial00/AEADHandCiphers

https://github.com/gundermanc/gundercrypt (not tested)

https://github.com/mhearne-usgs/handcrypt (related but not secure)

https://github.com/abidahmedgwu/cryptography (related but not secure)

>>985262

Also Redeye has a Blueye counterpart https://github.com/pvial00/BlueDye

http://www.pcg-random.org/paper.html

https://github.com/blake8086/sarah-cipher

https://huttoncipher2.netlify.com/ and http://dynamicsquarecipher2.epizy.com

https://www.youtube.com/watch?v=Bi_WdloDPrc

https://eprint.iacr.org/2008/473.pdf

https://www.reddit.com/r/crypto/comments/47axgy/hexfair_encryption/

>>985215 (OP)

Every text about cryptography I have read has said how you shoudn't make your own algorithms but from purely cryptographic security perspective is there really any downside for making your own algorithm, encrypting with it and then encrypting with industry standard algorithm again, as opposed to just using industry standard algorithm?

Obviously excluding the chance that your extra code might add security vulnerabilities.

In many applications the performance overhead would easily be overshadowed by gains from custom encryption.

I would imagine it to be hellish situation for the alphabet soups if every application had custom encryption algorithms that they would have to crack, in addition to the industry standard algorithms?

>>985557

>but from purely cryptographic security perspective is there really any downside for making your own algorithm, encrypting with it and then encrypting with industry standard algorithm again, as opposed to just using industry standard algorithm?

In general no, it's just a waste of time.

>>985557

>Every text about cryptography I have read has said how you shoudn't make your own algorithms

This only applies to brainlets. I'd recommend not starting from scratch though and instead starting wish some primitives that are recognized to be secure.

What about secure hashes? Don't you want those to be slow as possible? Isn't that why bcrypt is used so often?

>>985262

nice links anon

The only thing for symmetric cryptography is this: https://keccak.team/files/CSF-0.1.pdf

>>985597

>Don't you want those to be slow as possible?

Only when hashing low entropy stuff like passwords. If the data your hashing has an entropy of >=128 bits then it is practically impossible to brute force a collision. If the entropy is low (passwords like s3cr3tp4ssw0rd) than you can easily brute force a collision. To guard against that you hash passwords with a slow hash function to make brute forcing infeasible.

>>985625

i accidentally two wordd

>The only thing for symmetric cryptography is this

The only thing you need for symmetric cryptography is this

>>985557

1. dangerous

2. even if you have the skills, it is a waste of time

It is better to just combine existing libraries to an amalgamation e.g. cascade ciphers, multihash like x11/13/14/15 or hashing multiple hashes then XOR/concat it.

https://eprint.iacr.org/2016/723.pdf

>>985597

BCrypt/Scrypt and its derivatives relies on existing hashes and ciphers, using repeated operations to increase time complexity.

If you are only hashing larger files just use KangarooTwelve, BLAKE2 or Skein512 (or SHA2/SHA3/BLAKE/Skein1024 if you want it to be slow)

> KangarooTwelve > BLAKE2 > SHA384/512 > Skein512 and BLAKE512 > SHAKE128 > BLAKE256 > SKEIN1024 > SHA3-256 and SHAKE256 > SHA256

>>985627

Keccak is one of the best thing in the future, but then ARXs like BLAKE and Skein is just comfy.

If you want to see which one is comfier, try python golfing Keccak vs BLAKE and Skein

>>985870

https://tahoe-lafs.org/pipermail/tahoe-dev/2010-June/004575.html wew

https://eprint.iacr.org/2012/354.pdf

Who here wants to roll their own crypto using existing libraries?

>>986417

I'm rolling my own libraries using existing cryptograhic algorithms.

>>985557

if you're retarded, your own primitives can add oracles and other problems, even when combined with industry standards

>>985870

>hur dur rolling your own anything is bad

okay then go to stackoverflow where you get upvotes to say that

>>986417

roll your own primitives or roll your own protocols? stackoverflow autists can't distinguish beside the two. when you get into a discussion about rolling your own anything and adding the word crypto into the discussion, they go crosseyed and NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO NEVER ROLL YOUR OWN CYPTO

>>986446

Roll your own protocol with combinations of different pre-existing primitives

How do I get start on this stuff???

>>986446

>>986663

https://github.com/TokTok/c-toxcore/issues/426

You NEVER roll your own crypto, unless you absolutely know what your doing and have let others who also absolutely know what their doing review your shit.

>>986844

>if someone steals your private key they can decrypt your communications

No shit captain obvious. That's a design feature of the crypto protocol, not a flaw. Secure your private key better you gigantic faggot. Don't just share your password/private key with random idiots.

Homomorphic

https://github.com/shaih/HElib

https://github.com/tfhe/tfhe

https://github.com/Lab41/PySEAL

https://github.com/Georeactor/crypto-geofence

https://github.com/jonaschn/awesome-he

>>987033

Either you are retarded or pretending to be retarded.

If you are using a secure key exchange protocol then an attacker can only impersonate you if he obtains your private key.

If your shitty protocol is vulnerable to KCI (Key Compromise Impersonation) then an attacker can furthermore impersonate others to you without having obtained their provate key.

Challenge: Golfing BLAKE2 vs Skein vs SHA2 vs SHA3

For SHA3 half of the work is done for you

https://www.nayuki.io/res/cryptographic-primitives-in-plain-python/sha3hash.py

post-quantum cipher.

anything else is nigger tier.

you'll realize me saying this in 2018 was right when current_year != 2018

>>989043

>I'm a stupid nigger that has no clue about cryptography and can only spout buzzwords liek post-quantum

http://www.pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf

http://cr.yp.to/hash/collisioncost-20090823.pdf

This thread is a mistake.

>>989265

Care to give an alternative?

>>985255

“Most standard in the industry”

Industry standards are worthless.

>>989984

>alternative

to what?

>>990033

To PQCrypto, or cryptographic standards in general

>>990056

Didn't you read the PDFs I posted????? What we currently have is already quantum secure.

>>990065

Quote

"A closer look reveals, however, that there is no justification for the leap from “quantum computers destroy RSA and DSA and ECDSA” to “quantum computers destroy cryptography.”"

It said that RSA, DSA and ECC are dead and we need alternatives.

>>990067

This thread is not about RSA, DSA or ECC though.

You have to work on your reading comprehension, kiddo.

>>990290

PQCrypto is for replacing RSA/ECC

>>990320

Holy fucking shit. Do you have negative IQ or what?

>>990365

Tangential faggotry.

>>985215 (OP)

DES, encoded with base64 for extra security

Important information such as passwords should be encrypted with MD5 and then Base64. This will be bulletproof against hackers trying to steal passwords.

>>997187

>>997190

kek.

On a serious not, why would Ryzen have special operations for SHA256/SHA224?

>>985870

Blake2 is fast as fuck.

>>997220

Because x86 is not bloated enough.

>>997230

Boi!!!!!!!!!!!!!!!!!!!!!!!!!!