This seems to be the gold standard on Scrypt on KZread, thanks!

I've been using the Scrypt Algorithm for my full disk encrypted hard drives for two years now. The more RAM & more newer model CPU you have. You can create the time that a hacker has to try each brute force attack per attempt. Take note, this also slows down the legitimate user to try also the same times per entering the password in. I got it to where a hacker could only try one try every 4 minutes and 54 seconds per each password cracking attempt. The NSA fears strong encryption, what's really the best thing against them cracking our encryption. Is counter measures and fail safes. This is exactly what the scrypt algorithm does.

Thanks! It's been easy to understand in the way that you explained it.

Thank you! This video is very well explainded.

Great explanation, thanks for the video

thanks a lot !! great video!!

❤❤❤❤

How do the iterations actually work? Are you using the salt to produce a psuedorandom number during each iteration in conjunction with the loop function? Is the loop hashing the input each iteration with some other input like a number, random number, previous hash output, etc?

@yusufefl

5 жыл бұрын

www.tarsnap.com/scrypt/scrypt.pdf .. SMIX is a kind of block hasher. Think your message is divided into blocks. Find the hash of the first block XOR it with the next block and HASH again. The used hashing function is Salsa20. So it is impossible to find the solution without iterating through each block sequentially. So this makes the process to be hardly parallelized.

Noob question from a crypto-noob: At 9:05 I thought private keys are not to be shared? or did you mean that in some other way?

@skibbli

7 жыл бұрын

MAC / HMAC do not require the use of a private key in the same sense as ECDSA or RSA. The "private key" in his example is better described as a shared secret between the two parties, because this scenario is not asymmetric encryption. Merely a hash function. This is often useful when authenticating with a website's API, as an extra measure to prevent tampering, and providing key expiry and special permissions. It's important to note: In the case of RSA and ECDSA, along with many other asymmetric encryption algorithms where you must generate a key PAIR (private and public), you do NOT share your private key under any circumstance.

@manirkm1

7 жыл бұрын

Got it, Thanks for the reply

@bengregori2911

4 жыл бұрын

​@@skibbli Building on this, would this method be vulnerable to a MITM attack? If someone can intercept the shared secret, then the message can be decrypted. I suppose that N, R, P, and dkLens cannot be extracted from the key to re-encrypt the message once intercepted and therefore is tamper-resistant, but wouldn't it still be readable by an attacker?

is there a standard doc for this algo?

@yusufefl

5 жыл бұрын

www.tarsnap.com/scrypt/scrypt.pdf

It's important to say, that a MAC is missing the security goal for alice to prove to third-party that a message is created by bob, because it also could be created by alice herself. MACs only prove for alice, that a message is created by bob, because alice knows, it was not created by herself.

It's me or you confused rainbow table and brute fore all the time ?