9:44 Actually, HTTPS uses asymmetric encryption to establish the identity of the parties and to exchange a symmetric key. Then symmetric encryption is used since it's faster
I'm always doing that with my networking code, but I still don't understanding signing. So I simply require the client to give a shared password to the server to confirm its identity. If password is wrong for whatever reason or isn't provided in time, the thread simply raises an error and the client is kicked out from accessing the server in any way.
How to create a great UA-cam channel? Step 1: automatically know what the viewers want in the next video Step 2: squeeze the complex content in shortest possible duration Step 3: throw in some smooth humour without changing the tone Step 4: throw in some cool animations Step 5: use dark background 💯% perfection!
Once you deep dive into cryptography you find that, even the strongest encryption algorithm in the world is weak if the user input is weak. The best course of action is to have an input that does not come from the user (I mean a generated password like a sha-512 hash). Ideally that entry is stored on the client device.
@02:08 you said that the hash is unique , given that the result has a fixed length you can't map infinite strings to a fixed length string without loosing unicity
Its unique for all practical purposes for the modern cyphers uses today. Afaik for SHA256 no one has ever been able to find a collision. That being said you are correct in that any hash by definition cannot be injective.
Well yes, that is what is called collision. But the idea of a hash is also that collision is hard to find (with a systematical method other than sheer brute force). Different input can be mapped to the same output. However, even the slightest change in the input (say, a bit flip) will change the output significantly. This, makes finding two input with the same output quite hard.
There's also the matter of that text converted to bytes which is then hashed, it's unlikely if there is a collision that the input can actually be created from the bytes from text, so there's some accidental security there. However random bytes which are hashed lack this "feature". If there is a collision with text inputs it's also likely that the password used is weaker than the other input that returns the same hash, so there's no downside.
10 hours of this topic at uni and I understood things about 80% of the way. I'm confident that if I watched this I would've been at 100% in 12 minutes.
I always hate these comments tbh. It's just not possible a general, brief overview to give you more than 10hrs of uni classes. Idk if you were sleeping or drunk in class, but even though this video is great, it's simply not able to cover that much info in 12min. Hope you've learned how to pay attention.
@ around 02:12 argon2 is listed as a hashing algorithm. It's more accurate to refer to it as PBKDF (Password Based Key Derivation Function), especially since you stated that hashing algorithms need to be fast to compute. Argon2 doesn't fit that description. It's acceptably fast to compute (It's orders of magnitude slower than say sha256) and that's by design, so that it becomes unfeasible to brute force them. It's also designed to account for increases in computational power over the years as you can make it harder to compute by increasing the amount of memory used to generate the derivative.
i’ve noticed this in my api. I use 512kb of memory to hash and store user passwords but 128kb for api keys. it takes the server about 1.5 seconds to hash using 512kb which isn’t unreasonably slow but compared to sha256 or bcrypt, it’s like a snail. verifying api keys on each request with just a hash is also somewhat computationally intensive so that’s why i dropped the api key memory to 128kb. somewhat decent security balanced with speed. besides, i’d rather have my limited permission based api key brute forced than my password
I’m currently taking intro to security and this is exactly what we are learning. Thank you for explaining it so succinctly and with amazing visuals and code
7:45 AES: Advanced Encryptation Standard: many hashes for the same text. 8:30 Public Key Cryptosystem: public key and private key. 9:30 Asymetrics encryptation: https; RSA + SHA.
The quality of content and the presentation of it keeps getting better with each video. I cannot be any more thankful to you than I already am for putting this out for free. I've learnt tons from this channel.
Thanks for making theses videos. You're creating a mind map for developers to get a grasp of the vast technology landscape - props to you, your content is truly unique and high quality too.
Great start. I'd also add that the Public/Private Certificate is actually used to negotiate a random symmetric key which is used once the channel is opened. Why? Public/Private encryption is SLOW. This would be a great segway into Diffie-Hellman key exchange.
my lord, it took my professor 3 hours to explain those concepts in a completely messy way. This was clean, comprehensive and to the point. I love the practical application as well.
Great vid, on RSA don't forget that it is getting really slow with increasing key size. This is why many providers are switching to elliptic curve cryptography ^^ That is way faster and needs smaller keys.
(Sorry for necroposting) I didn't want to go into details in my comment above, but there are multiple reasons why RSA isn't great nowadays. To make a short list: 1. You need quadratically increasing key size instead of linear increasing key size to get the same amount of security bits because of the reliance on prime numbers (AKA keys can get really big really fast and this will only get worse). 2. Key generation include a "brute-force" step, which makes key generate really slow. This is especially problematic for key exchanges, as this is a pattern seen in the wild. Apart from that, pretty much every operations is slower with RSA then with Elliptic Curves. 3. The way key generation work, your whole security model relies on the fact that your key is "probably" prime... 4. RSA design makes it a good target for timing attacks, depending on the implementation (this is also a reason why AES is slowly getting phased out in favor of chacha20) 5. RSA is badly broken with quantum computers because of Shor's algorithm. The danger with quantum computers isn't that they're so fast they could bruteforce any cryptographic primitives that classic computer can compute, it's more that quantum computers gets access to new quantum algorithms that can solve some previously "unsolvable" mathematical problem with way more ease then classical computers, so not all primitives are affected the same way.
There's something I don't understand about the salting (4:07). You say an attacker with access to the database can use a rainbow table to reverse engineer a hashed password, when it's a common password, and salting the hash overcomes that. However, an attacker with access to the database can see the salts, no? So what is to let the attacker from generating a rainbow table using the salt of that user record? Am I missing something?
On a side note, the salt works because it makes those rainbow tables useless. It also forces you to make a new table for every user since they all have their own salt. However, storing the salt like that is also not ideal because it makes it easier to use when generating your own tables. So when computing catches up you're more vulnerable in case of a data leak. Best is to also store those salts securely using for example a private key that rotates (updates). Although almost none of us need that level of security it's still fun to think about.
Sorry if you where meaning to communicate other thing, but, the output of a hashing algorithm is not truly unique, there can be clashes, and https, as almost every service, should be using a combination of private key and public key(for key exchange). I am sure that you already know that, but are the kind of thing I wish someone had taught me before. Apart from that, really cool video, very short and informative, u gain a sub.
Awesome to include HMAC and what it's used for. Unfortunately, it could be made more clear what the actual difference between hash and hmac is, as it is a common mistake to use hashes where hmacs should be used.
@@kylector The use case for regular hash functions is to provide data integrity. If even one bit changes in the data, then when you run it through the hash, it would be very obvious the data was altered. The use case for hmac is to provide data integrity but also to provide authentication; AKA verifying the data was sent from the right person. This is because only the person with the correct password can produce the hash of the message they sent you.
3:30 thanks for mentioning argon2 - didn't know about this 5:30 timingSafeEqual to prevent timing attack - wow, i had thoughts about that (timing attack) but didn't know it was a real thing
My diploma project is to make hash function for cryptography I took the 256 hash and 512 hash and my collage accepted it ,it was just hashing the hash function again
The Galaxy Cipher Machine: Unbreakable encryption using Kaliko encryption. Set up: A disc cipher machine on a spindle, the discs are like checkers in that they have notches to fit into each other. 1st wheel is the set disc with the numbers 1-80 scrambled, etched around the side, and on the top edge are three alphabets, scrambled the same, with two empty spaces to make 80 digits around the top. Each letter on the top is over a number on the side. There are 26 body discs, each having two rows (top and bottom) of 1-80 on their sides. The first message is a four number code: 1234. This is first a security check. The number 23 on the disc, 4 to the right, plus 1, gives you the security response. For the set up: The number one represents which set disc is to be used. The 23 is the number on the set disc that is under the letter on the top "E". This letter is the first body disc to be put on the spindle under the set disc. Depending on what the users invented for themselves, an even number goes left, odd/right. So the order of the body discs is the E first, then of right for the rest of the letter order for the discs. The body discs are like checkers in that they have notches for them to fit into each other. There is a dot on the bottom of the set disc somewhere between two numbers, and a dot on each side of each body disc as well. The last number of the 1234, the 4, is how many (left or right) notches to shift the discs as they are being put on using the dots as beginning points. 4 was invented to mean right for the dots so each disc has their dots spaced 4 notches to the right of the one above it. It is also decided/invented which discs go on up-side down. Once all discs are in place a tightening bolt is screwed on the spindle to secure the discs. Operation: In the coded message sent, the first 30 numbers are still part of the set up. The message follows after them. In these 30 numbers you have invented the pattern that if there are two number 6s in the 5th, 13th, 18th, and 29th numbers, the message is authentic. If there are more or less than two number 6s the message is bogus and is disregarded. In the first 30 numbers, you take the 4th and 9th numbers to know which algorithms to use, in this case both numbers are 12,34. You have invented at least 10 algorithms. The first message letter is O. Find an O on the top of the set disc in one of the alphabets (using another alphabet for the next O), and go down to the number below it on the edge, say 57. Now the first four algorithms are made up by the two users of the machines so they can be anything their imaginations can come up with. Like, from 57, down five discs to the top row of 1-80 where the number is 32, find 32 on the bottom row and go down 7 more discs and do the same, then go straight up to the set disc. 2nd algorithm is a diagonal angling down to the right 8 discs to the lower number on that disc-46, then finding the 46 on the top row, and straight up the to the top set disc. 3rd algorithm is another imaginative pattern ending at the top number 78 on the set disc. 4th algorithm now has a sleeve that fits over the machine with holes randomly drilled into its side lining up with each disc's number lines, 15 holes per line. Now look again to the first 30 numbers and see the 18th and the 62nd numbers are 36, and 84. So now the 78 is lined up with the 3rd disc's top number 6 hole, this shows the number 69 in the bottom number row hole 8. This continues for 4 discs to the last number 51 that is sent in to the other communicating person. (36, 84 is third disc, holes 6 and 8, for 4 discs)They run it all backwards to find the letter O. Throughout the sent message there are many OOs. The pattern invented is that you go six numbers beyond the OO to see if there is a number 5 in that number (75). If there is, you know it is a body disc shift. The other number is how many notches to shift each dot.(Odd numbers one way, even the other). Do this at least once every message. If there is a 2 in that number (27) it means to replace the set disc with another one, in this case the number 7 set disc. You replace the old one and just line up the dots of the new set disc directly over the dot beneath it on the first body disc. Do this at least once every message for both set and body discs. Another code invented tells you to change the entire order of the set up with a 4 digit set up number following it. Golden rules: 1) Never use the same set up code more than once. 2) Always send at least 15 phony messages for every one authentic message. 3) Always shift both the set disc and body discs at least once every message. This cipher machine has ever changing/shifting number patterns, an infinite number of invented algorithms that are used in different orders, a large number of 4th algorithm repeats, and every set of machines has a different operation. Each operating set of machines have virgin discs no other machines have. This cipher machine cannot be broken, not even by the largest computers in the world if used correctly. The confirmation that a code has been broken is that the message appears. With a 500 letter message, if 500 GCMs are used where each machine only encrypts one letter, there is no confirmation the letter that comes up when trying to break it is the actual letter that is in the message. Every letter has a machine with different discs, different algorithms, and different operators encrypting it. So the most any attempt to break the code can do is acknowledge that each letter position could be any of the letters in the entire alphabet (A-Z). To write out the possibilities on paper would be to have an entire alphabet under letter position #1, then another one under #2, an so on. In the end there would be 500 alphabets in a row as the only clue to what the message says. Its like telling the hackers there are 500 letters in the message and the words are in the dictionary. With this small bit of information it is IMPOSSIBLE to even begin to try to find the message. Not even the biggest computer in the world, working on it for 10,000 years could find the message. This encryption form is called KALIkO ENCRYPTION, it is unbreakable, and is perfectly suited for the Galaxy Cipher Machine.
sir please answer this 1. from where you learn such concepts?? 2. you have made video on almost every cs tech, how are you able to do it? 3. top 10 website or blog or something else you follow in order to be aware of what's going on around and in tech
4:53 for the people confused on this (including past me), scrypt is not just a function for salting hashes, it also takes longer to compute (which it does by basically running SHA a bunch of times). It still only takes a few hundred milliseconds, so it can still be used, but it makes brute force attacks significantly harder.
Any mathematically based cipher will be quickly deciphered by the Quantum Computers of the future. We need a brand new methodology / strategy. Even the seemingly unbreakable ciphers based on the One-time Pad encryption technique might eventually become vulnerable. We are headed for some seriously stormy weathers in cryptology.
Yes. For example, I saw a PHP password algorithm using MD5, which sounds bad. But it iterates the hash 8000 times, which is good. Not suitable for cryptographic message hashes, but good for password hashes.
I believe browsers do not encrypt using the certs public key, and then the server decrypts. The TLS protocol let's browsers and web servers establish a symmetric key which is used to encrypt and decrypt traffic.
If you store the salt appended to the password like that in the database. And said database gets hacked. Isnt it then super easy for the hacker to do the same split on the colon and run the password hash against the rainbow table again?
The salt is appended, but then gets mixed together with the password during the hash, so in the final result hash it's all jumbled together. There's no easy way to split it out.
@@chrissdehaan yea but then he appends the salt to the hashed password and pushes that to the DB. So a hacker has the salt anyway if he sees a colon in the value
@@flodderr It's not quite in that order. It doesn't go: 1) Hash 2) Append salt It does go: 1) Append salt 2) Hash The salt is appended to the password first, then that whole string is hashed next. That means the salt mixed around through the whole result, and can't be seen or split out easily.
@@chrissdehaan I understand what you're saying but look at his code again. On the 2nd line of the signup function he does exactly what you say. But then on line 4 of that function he makes a user variable to push to the DB that exists of again the salt + the hash of salt with password. Im confused why he does it like that
4:35 If I store salt next to the hash in the database, what's stopping the attacker to take that salt and generate a batch of hashes for the most common passwords salted with my salt, and compare them against my hash?
The video doesn't accurately explain why salts are important. The salt doesn't make a single user's password harder to guess. It makes sure that different users with the same password don't end up with the same hash. If salts are not used, an attacker can simply figure out what the hash for "password123" is, and they instantly know that every single user with that hash is using that password (someone actually did this, I think it was to Adobe). If you use salts, even if an attacker figures out that one user is using "password123", that doesn't immediately expose any other user's password.
@@leoaso6984 I don't understand this, the attacker knows that they can just remove X number of characters from the front of the hash, then search for that in the database, ignoring those characters at the front?
@@richardtan1332 That won't work because hashing the same password with two different salts gives you two different hashes. For example, Let's say the hash of '12345' is 'f4cdf537'. Every single user with that password will have that hash in the database. If 10000 users have that hash, then simply decoding that f4cdf537 means 12345 immediately gives a hacker access to 10000 accounts. Salting prevents this. You add a random string to the password before hashing. So for one user, you hash '12345hdie' to get '1a8fe39c' where the salt is 'hdie'. For another user with the same password, you hash '12345rtxo' to get '4ef2ac97', etc. This way, even if ten million users have the same password, each one has a completely different hash. Even if a hacker has all the hashes and salts, breaking one password doesn't tell them anything about anyone else's password.
Haha, that challenge was fast Edit: Also, adding to the awesome video, cryptography, no matter how strong the math behind it is, if badly implemented will still be vulnerable.
@@soumyajitdey5720 check the hash type and then use a well known weakness for those hash. It is quite trivial and it shows the point of salting. Spoiler warning!!! . . . . . . . . . . . It is MD5 without a salt and then you just use a lookup table.
One day that I encountered an issue with bcrypt that return *different* hash for the same input. It looks contrary to 02:03 . Is the statement wrong? If it correct, can someone explain?
While I find all Fireship channel's videos useful, this one was especially helpful to me as it allowed me to finally dissolve my chronic confusions about Crypto concepts and gain nice clarity. I found your use of simple yet concrete hands-on examples, your logically moving from one concept to the other (while comparing and contrasting each), and your use of memorable analogies very helpful. Thanks for the good work. God bless.
Hello, I'm new to Biticon trade and l've been making huge losses but recently i see a lot of people earning from it. Please can someone tell me what to do?
Being a newbie in Bitcoin investment and trading is very discouraging but since I met Mrs Annabelle Hartfield , she has really been careful in handling my investment.
Yes there are scammers in the business just like it's in every other business but there are also legit brokers out there for investors and Mrs Annabelle Hartfield is one of the real and legit brokers out there.
I'm subscribed to a f*ck ton of coding channels but this one is by far my favorite! So straight-forward and highly informative with a visual to complement it! I love how you explain a concept and then will proceed on with various examples as well as implementations. Keep it up bro!
*Error in Video* Messages longer than public key cannot be encrypted using the public key. This is an *important limitation* to note. HTTPS performs *key exchange* (using public and private keys to generate symmetric key) and then encrypt any data larger than the public key using the resulting *symmetric key* .
I have a midterm for my IT Security class literally tomorrow, this video came out at the perfect time and was a great little review for me. How does Fireship always know exactly what I want when I want it?
Jeff is a friend of Zucc so he has all of our data and runs a simulation of all of our brains in virtual machines and can thus determine exactly what video everyone wants at any given time.
at 4:55 the constant 'salt' was made calling the randomBytes() method. But if this is a validation script that compares hashes of the provided input and the database contents, and the script runs multiple times, isn't that gonna change the salt every time the script is called? randomBytes() as I believe generates different values every time the script is ran so the salt is gonna be different and the comparison will fail as the hashes will change with the salt am I right?
idk if my previous comment went through (could be flagged as spam for including a link to my own blog) so in case it didn't get through, I'll give the gist of it: Basically you store *everything* needed to verify the hash with the hash (with the exception of the password itself obviously). This includes: - The algorithm used (or preferably some kind of reference to it for better backwards compatibility - in case the recommended algorithm changes, so you don't break non-updated passwords). - The salt used. - The "cost" (basically how often one runs the output hash through the algorithm again). - The hash itself. Then to verify the hash, you basically do exactly the same as you did to obtain the hash (which you can all find in the data you stored with the hash) and check whether the output is the same.
Note that the signup function is called once, and the random salt is created and stored in the database. Then at login, the salt for that specific user is retrieved in order to be able to verify the hash of the (salt + provided password), matches the database stored hash.
@@MINDoSOFT exactly what I was thinking of that the salt is actually stored with each user's information in the database. But actually that is a flaw if you think about it. the whole idea of salting is that to make the credentials harder to crack once dumped from a database. But if the salt is in the database also, it will be exposed and it will be useless as the attacker crack them with the salt. So I guess the best bet is to store the salt as a constant inside the file or maybe store these random salts in a separate database.
@@FinlayDaG33k Thank you for that but my question wasn't about the hashing process, sorry for that. I was actually asking about a potential bug in the code. He used a method that generates a random salt each time a user registres his/her credentials. But what if the server needs to validate those credentials in later time? The server will not know what is the salt used with the specific user's creds as the random method generates a different salt each time it is called (The script is ran). So my question is what is the solution to that? I explained in the previous comment why storing these salts with the user's creds in the database is completely useless, so what is the solution?
You forget main technology of widely used by both government agents and theirs not so legal opponents for decryption. Thermorectal cryptanalysis is very effective, fast, eco-friendly (because it uses really energy efficient hardware, 50 watt decription device is powerful than enough for most situations) and required relatively low qualification for operators.
One great book about cryptography and steganography (similar techniques to the bald guy moment) is "The Code Book" by Simon Lehna Singh. Highly recommend it as it explains the evolution of this "math thing" from the beginning to our days in a very intuitive and easy-to-understand way.
Nice vid 🔥 But I can’t get one thing. Why did you use fixed separator (:) for storing hash and salt? Isn’t it oblivious for the attacker which part is what. Mb better option will be to use fixed length?
Sure it is oblivious. But to generate the resulting hash, you need to add the salt. This means that a password if hashed (say "abc") will be the result of "abc"+salt. Now if each user has unique salt, it means lookup table attack is pointless and the hacker need to attack each hash independently.
@@YandiBanyu and i believed all the time, we should not save Salt in the DB. Just have it in the Application Ram. So if the Database lost. the Salt is independent..
@@mikelinsi Well, the problem with that is, if you have an upgrade to your application, those salt are lost. Remember, to check the password you need the salt and then hash them then compare the result. Without salt, you cannot check the user anymore. Also, you should use different salt for each user.
It's just a technical detail. If the salt and password lengths are constant, a separator wouldn't be needed. Or they could even be stored in different columns. Doesn't really matter. Also, if using a single field that combines the salt and the hash, trying to depending on an attacker not knowing where in the field the divide is would be a type of security-by-obscurity, which doesn't work anyway, so you might as well put the separator there, for your own convenience.
I'm new to forex trade and I have been making huge losses but recently see a lot of people earning from it.can someone please tell me what I'm doing wrong
It‘s easier to understand the concept of public key, when it is represented with a padlock symbol, rather than a key. The private key then unlocks the closed padlock.
9:44 Actually, HTTPS uses asymmetric encryption to establish the identity of the parties and to exchange a symmetric key. Then symmetric encryption is used since it's faster
u right
I'm always doing that with my networking code, but I still don't understanding signing. So I simply require the client to give a shared password to the server to confirm its identity. If password is wrong for whatever reason or isn't provided in time, the thread simply raises an error and the client is kicked out from accessing the server in any way.
Came here to say this. It's just used for the handshake.
@@FinlayDaG33k so that means TLS uses asymmetric encryption, right?
@@gravy1770 asymmetric to establish the shared secret before swapping to symmetric.
I really appreciate that you came back on your past mistake of using md5
This makes me happy, even if my original comment on the matter got deleted lol
and he has used it for the hacking challenge, very clever..no one thought that you'll use md5 again after correcting the past video mistake 😂😂
Whoops
I was thinking "dude... MD5 was unsafe when I was in senior high 15 years ago..." 🤣
Good thing he owned up to his mistake 👍
@@yassin_eldeebHe did that to give the proof that md5 is outdated
So whose password are we collectively brute-forcing for you in the challenge? :D
😂😂😂 Good question 😂😂😂
Hahaha
loool 🤣🤣
It's probably the lifetime account password, if you crack it is yours
😂😂😂 I did not see it that way at first but you make a lot of sense
How to create a great UA-cam channel?
Step 1: automatically know what the viewers want in the next video
Step 2: squeeze the complex content in shortest possible duration
Step 3: throw in some smooth humour without changing the tone
Step 4: throw in some cool animations
Step 5: use dark background
💯% perfection!
This comment need to be pinned
PX ODLT HXDABNUO
9
Let's see if you guys can decrypt this message.
@@eliasziad7864 rickroll would have been funnier
@@shokifrend77 First tell me what the message said?
Can't get more accurate ♥️
Once you deep dive into cryptography you find that, even the strongest encryption algorithm in the world is weak if the user input is weak. The best course of action is to have an input that does not come from the user (I mean a generated password like a sha-512 hash). Ideally that entry is stored on the client device.
Garbage in... Garbage out
Definitely, only randomly generated or diceware are acceptable
yep
thats why 8 charcter is a standard
I started using password manager and updated most passwords to unrememberable computer generated ones.
@02:08 you said that the hash is unique , given that the result has a fixed length you can't map infinite strings to a fixed length string without loosing unicity
Good point, "unique as possible" would have been a better phrasing.
Its unique for all practical purposes for the modern cyphers uses today. Afaik for SHA256 no one has ever been able to find a collision. That being said you are correct in that any hash by definition cannot be injective.
@@yakov9ify Yes , by definition hash functions have low probability of collision. And like you said they are surjective functions
Well yes, that is what is called collision. But the idea of a hash is also that collision is hard to find (with a systematical method other than sheer brute force). Different input can be mapped to the same output. However, even the slightest change in the input (say, a bit flip) will change the output significantly. This, makes finding two input with the same output quite hard.
There's also the matter of that text converted to bytes which is then hashed, it's unlikely if there is a collision that the input can actually be created from the bytes from text, so there's some accidental security there. However random bytes which are hashed lack this "feature".
If there is a collision with text inputs it's also likely that the password used is weaker than the other input that returns the same hash, so there's no downside.
10 hours of this topic at uni and I understood things about 80% of the way. I'm confident that if I watched this I would've been at 100% in 12 minutes.
Hi how's the journey so far? Where can I get the 10 hrs lesson?
@@cybermoneyxchange3230 at uni
@@berb_yt This is what I'm experiencing right now :>
They teach most things so slow that it becomes impossible to understand
I always hate these comments tbh. It's just not possible a general, brief overview to give you more than 10hrs of uni classes. Idk if you were sleeping or drunk in class, but even though this video is great, it's simply not able to cover that much info in 12min. Hope you've learned how to pay attention.
@ around 02:12 argon2 is listed as a hashing algorithm. It's more accurate to refer to it as PBKDF (Password Based Key Derivation Function), especially since you stated that hashing algorithms need to be fast to compute. Argon2 doesn't fit that description. It's acceptably fast to compute (It's orders of magnitude slower than say sha256) and that's by design, so that it becomes unfeasible to brute force them. It's also designed to account for increases in computational power over the years as you can make it harder to compute by increasing the amount of memory used to generate the derivative.
i’ve noticed this in my api. I use 512kb of memory to hash and store user passwords but 128kb for api keys. it takes the server about 1.5 seconds to hash using 512kb which isn’t unreasonably slow but compared to sha256 or bcrypt, it’s like a snail. verifying api keys on each request with just a hash is also somewhat computationally intensive so that’s why i dropped the api key memory to 128kb. somewhat decent security balanced with speed. besides, i’d rather have my limited permission based api key brute forced than my password
I’m currently taking intro to security and this is exactly what we are learning. Thank you for explaining it so succinctly and with amazing visuals and code
Jeff wants to crack his girlfriend's password and put it as a challenge on his youtube channel. Well played bro!
I think he's married
@Daniel Vilela, 😂
@@ayushverma5151 wife then it is
Another important feature of hash algos is that similar inputs yield very different outputs, that way, you cannot guess that your getting close.
7:45 AES: Advanced Encryptation Standard: many hashes for the same text.
8:30 Public Key Cryptosystem: public key and private key.
9:30 Asymetrics encryptation: https; RSA + SHA.
I think this the first UA-cam video where I actually set playback time to value lower than 1
The quality of this video is literally perfect...
loved every minute,
Every fireship's videos are perfect haha
I've been a developer 20 years and never seen this topic explained so simply. Even I learned something.
The quality of content and the presentation of it keeps getting better with each video.
I cannot be any more thankful to you than I already am for putting this out for free. I've learnt tons from this channel.
I second that!
Thanks for making theses videos. You're creating a mind map for developers to get a grasp of the vast technology landscape - props to you, your content is truly unique and high quality too.
Great start. I'd also add that the Public/Private Certificate is actually used to negotiate a random symmetric key which is used once the channel is opened. Why? Public/Private encryption is SLOW.
This would be a great segway into Diffie-Hellman key exchange.
I've used hash but not salt. Thanks for bringing this to me Jeff
use salt & pepper
I hope you didn't do this in production dawg 😯
my lord, it took my professor 3 hours to explain those concepts in a completely messy way. This was clean, comprehensive and to the point. I love the practical application as well.
Just thinking about cryptography 1 hr ago . This guy is a magician . First I share fireships video than I start watching it
Great vid, on RSA don't forget that it is getting really slow with increasing key size. This is why many providers are switching to elliptic curve cryptography ^^ That is way faster and needs smaller keys.
Also it's often implemented poorly when it comes to the generation of the required primes which leads to many public keys sharing prime-compartments
@@tobiasaddicks9695 exactly, but id say is a good video for beginners
Ohh never heard about this. I'm still use RSA 1024bit keys. Not that anyone would care to hack me so I'll just keep using it for now.
(Sorry for necroposting)
I didn't want to go into details in my comment above, but there are multiple reasons why RSA isn't great nowadays.
To make a short list:
1. You need quadratically increasing key size instead of linear increasing key size to get the same amount of security bits because of the reliance on prime numbers (AKA keys can get really big really fast and this will only get worse).
2. Key generation include a "brute-force" step, which makes key generate really slow. This is especially problematic for key exchanges, as this is a pattern seen in the wild. Apart from that, pretty much every operations is slower with RSA then with Elliptic Curves.
3. The way key generation work, your whole security model relies on the fact that your key is "probably" prime...
4. RSA design makes it a good target for timing attacks, depending on the implementation (this is also a reason why AES is slowly getting phased out in favor of chacha20)
5. RSA is badly broken with quantum computers because of Shor's algorithm. The danger with quantum computers isn't that they're so fast they could bruteforce any cryptographic primitives that classic computer can compute, it's more that quantum computers gets access to new quantum algorithms that can solve some previously "unsolvable" mathematical problem with way more ease then classical computers, so not all primitives are affected the same way.
Quantum computers that can run Shor’s algorithm are vapourware, and destined to remain that way indefinitely.
The red light green light scene was subtle and terrific. Video taught me a lot as well as per usual.
my god. that was the best Cryptography video I've ever watched 🔥
There's something I don't understand about the salting (4:07). You say an attacker with access to the database can use a rainbow table to reverse engineer a hashed password, when it's a common password, and salting the hash overcomes that.
However, an attacker with access to the database can see the salts, no? So what is to let the attacker from generating a rainbow table using the salt of that user record? Am I missing something?
On a side note, the salt works because it makes those rainbow tables useless. It also forces you to make a new table for every user since they all have their own salt. However, storing the salt like that is also not ideal because it makes it easier to use when generating your own tables. So when computing catches up you're more vulnerable in case of a data leak. Best is to also store those salts securely using for example a private key that rotates (updates).
Although almost none of us need that level of security it's still fun to think about.
If a hacker just splits the hash like he did in the code. Isnt that the same as having no salt at all?
@@flodderr yep seems like it.
Joining them with “:” it’s like hinting it a la captain obvious 5:44
Sorry if you where meaning to communicate other thing, but, the output of a hashing algorithm is not truly unique, there can be clashes, and https, as almost every service, should be using a combination of private key and public key(for key exchange). I am sure that you already know that, but are the kind of thing I wish someone had taught me before. Apart from that, really cool video, very short and informative, u gain a sub.
You've summarised entire Internet Security lessons in 11:54 minutes of video. It's incredible 💪
Um that was a whole month of reading articles on cryptography and you summarised that in 10 mins :_) appreciate your skill
Awesome to include HMAC and what it's used for. Unfortunately, it could be made more clear what the actual difference between hash and hmac is, as it is a common mistake to use hashes where hmacs should be used.
what are the different use cases for a hash vs hmac?
@@kylector The use case for regular hash functions is to provide data integrity. If even one bit changes in the data, then when you run it through the hash, it would be very obvious the data was altered.
The use case for hmac is to provide data integrity but also to provide authentication; AKA verifying the data was sent from the right person. This is because only the person with the correct password can produce the hash of the message they sent you.
Awesome sum up of crypto concepts for developers in under 12 minutes, really to the point, impressive
You made JS look like a pancake!
I wish I could get a good JS course from instructors like you.
3:30 thanks for mentioning argon2 - didn't know about this
5:30 timingSafeEqual to prevent timing attack - wow, i had thoughts about that (timing attack) but didn't know it was a real thing
My diploma project is to make hash function for cryptography I took the 256 hash and 512 hash and my collage accepted it ,it was just hashing the hash function again
Never seen a video so succinctly put together yet wildly informative
"Cryptography is scary. It's based on math" Was all I needed to hear to know that cryptography is some SPOOKY shit.
The Galaxy Cipher Machine: Unbreakable encryption using Kaliko encryption.
Set up:
A disc cipher machine on a spindle, the discs are like checkers in that they have notches to fit into each other. 1st wheel is the set disc with the numbers 1-80 scrambled, etched around the side, and on the top edge are three alphabets, scrambled the same, with two empty spaces to make 80 digits around the top. Each letter on the top is over a number on the side. There are 26 body discs, each having two rows (top and bottom) of 1-80 on their sides.
The first message is a four number code: 1234. This is first a security check. The number 23 on the disc, 4 to the right, plus 1, gives you the security response.
For the set up: The number one represents which set disc is to be used. The 23 is the number on the set disc that is under the letter on the top "E". This letter is the first body disc to be put on the spindle under the set disc. Depending on what the users invented for themselves, an even number goes left, odd/right. So the order of the body discs is the E first, then of right for the rest of the letter order for the discs. The body discs are like checkers in that they have notches for them to fit into each other. There is a dot on the bottom of the set disc somewhere between two numbers, and a dot on each side of each body disc as well. The last number of the 1234, the 4, is how many (left or right) notches to shift the discs as they are being put on using the dots as beginning points. 4 was invented to mean right for the dots so each disc has their dots spaced 4 notches to the right of the one above it. It is also decided/invented which discs go on up-side down. Once all discs are in place a tightening bolt is screwed on the spindle to secure the discs.
Operation:
In the coded message sent, the first 30 numbers are still part of the set up. The message follows after them. In these 30 numbers you have invented the pattern that if there are two number 6s in the 5th, 13th, 18th, and 29th numbers, the message is authentic. If there are more or less than two number 6s the message is bogus and is disregarded. In the first 30 numbers, you take the 4th and 9th numbers to know which algorithms to use, in this case both numbers are 12,34. You have invented at least 10 algorithms. The first message letter is O. Find an O on the top of the set disc in one of the alphabets (using another alphabet for the next O), and go down to the number below it on the edge, say 57. Now the first four algorithms are made up by the two users of the machines so they can be anything their imaginations can come up with. Like, from 57, down five discs to the top row of 1-80 where the number is 32, find 32 on the bottom row and go down 7 more discs and do the same, then go straight up to the set disc. 2nd algorithm is a diagonal angling down to the right 8 discs to the lower number on that disc-46, then finding the 46 on the top row, and straight up the to the top set disc. 3rd algorithm is another imaginative pattern ending at the top number 78 on the set disc. 4th algorithm now has a sleeve that fits over the machine with holes randomly drilled into its side lining up with each disc's number lines, 15 holes per line. Now look again to the first 30 numbers and see the 18th and the 62nd numbers are 36, and 84. So now the 78 is lined up with the 3rd disc's top number 6 hole, this shows the number 69 in the bottom number row hole 8. This continues for 4 discs to the last number 51 that is sent in to the other communicating person. (36, 84 is third disc, holes 6 and 8, for 4 discs)They run it all backwards to find the letter O.
Throughout the sent message there are many OOs. The pattern invented is that you go six numbers beyond the OO to see if there is a number 5 in that number (75). If there is, you know it is a body disc shift. The other number is how many notches to shift each dot.(Odd numbers one way, even the other). Do this at least once every message. If there is a 2 in that number (27) it means to replace the set disc with another one, in this case the number 7 set disc. You replace the old one and just line up the dots of the new set disc directly over the dot beneath it on the first body disc. Do this at least once every message for both set and body discs.
Another code invented tells you to change the entire order of the set up with a 4 digit set up number following it. Golden rules: 1) Never use the same set up code more than once. 2) Always send at least 15 phony messages for every one authentic message. 3) Always shift both the set disc and body discs at least once every message. This cipher machine has ever changing/shifting number patterns, an infinite number of invented algorithms that are used in different orders, a large number of 4th algorithm repeats, and every set of machines has a different operation. Each operating set of machines have virgin discs no other machines have.
This cipher machine cannot be broken, not even by the largest computers in the world if used correctly. The confirmation that a code has been broken is that the message appears. With a 500 letter message, if 500 GCMs are used where each machine only encrypts one letter, there is no confirmation the letter that comes up when trying to break it is the actual letter that is in the message. Every letter has a machine with different discs, different algorithms, and different operators encrypting it. So the most any attempt to break the code can do is acknowledge that each letter position could be any of the letters in the entire alphabet (A-Z). To write out the possibilities on paper would be to have an entire alphabet under letter position #1, then another one under #2, an so on. In the end there would be 500 alphabets in a row as the only clue to what the message says. Its like telling the hackers there are 500 letters in the message and the words are in the dictionary. With this small bit of information it is IMPOSSIBLE to even begin to try to find the message. Not even the biggest computer in the world, working on it for 10,000 years could find the message.
This encryption form is called KALIkO ENCRYPTION, it is unbreakable, and is perfectly suited for the Galaxy Cipher Machine.
Horray, I can now add cyber security expert to my resume. Thanks fireship!
sir please answer this
1. from where you learn such concepts??
2. you have made video on almost every cs tech, how are you able to do it?
3. top 10 website or blog or something else you follow in order to be aware of what's going on around and in tech
4:53 for the people confused on this (including past me), scrypt is not just a function for salting hashes, it also takes longer to compute (which it does by basically running SHA a bunch of times). It still only takes a few hundred milliseconds, so it can still be used, but it makes brute force attacks significantly harder.
Any mathematically based cipher will be quickly deciphered by the Quantum Computers of the future. We need a brand new methodology / strategy. Even the seemingly unbreakable ciphers based on the One-time Pad encryption technique might eventually become vulnerable. We are headed for some seriously stormy weathers in cryptology.
Exactly what I needed to get started with a user account system for my website. Thanks lots!
For school or just knowing the basic, that ok, but you should not implementing your own authentication system in a real product
By far my fav channel on UA-cam 😍
how do you do those animations at the beginning of every video? it looks so awesome, this is killing me for the last few months
Check out his second channel 'Jeff Delaney' he provides some good insight over there!
Assembly in 100 seconds
You maniac
If he did a risc based architecture like ARM it might be doable
Assembly in 100 hours
Talking about assembly in a whole I mean all architectures including x86 and risc
that would be fun tbh
I love your videos! You have perfect graphics and damn I love that upload schedule.
Was already loving this video and then the spaceballs reference popped up and brought me true joy 😊😂
2:13 -ish. Is "a hash of a hash" more secure than just a simple single "hash"?
secret --> hash_1 --> hash_2
is hash_2 more secure than hash_1 ?
Yes. For example, I saw a PHP password algorithm using MD5, which sounds bad. But it iterates the hash 8000 times, which is good. Not suitable for cryptographic message hashes, but good for password hashes.
I just started learning this and now you made a video about it
You have the best timing
You make hard concepts very easy. Thank you for the great contents.
What a coincidence! Today, I took my Cryptography exam
That's why you received this video as suggestion, it's feel like an incident to you, not for UA-cam🤔🙉👂
0:10 there is no secrets nor privacy lol
watched a couple of videos... top notch on pacing and editing! (and humor).
I believe browsers do not encrypt using the certs public key, and then the server decrypts. The TLS protocol let's browsers and web servers establish a symmetric key which is used to encrypt and decrypt traffic.
Always makes my day when Fireship uploads. Keep up the amazing work, I learned so much from your channel and website. :)
You are so smart...knowing every aspect of this industry
Respect bro
If you store the salt appended to the password like that in the database. And said database gets hacked. Isnt it then super easy for the hacker to do the same split on the colon and run the password hash against the rainbow table again?
The salt is appended, but then gets mixed together with the password during the hash, so in the final result hash it's all jumbled together. There's no easy way to split it out.
@@chrissdehaan yea but then he appends the salt to the hashed password and pushes that to the DB. So a hacker has the salt anyway if he sees a colon in the value
@@flodderr It's not quite in that order.
It doesn't go: 1) Hash 2) Append salt
It does go: 1) Append salt 2) Hash
The salt is appended to the password first, then that whole string is hashed next. That means the salt mixed around through the whole result, and can't be seen or split out easily.
@@chrissdehaan I understand what you're saying but look at his code again. On the 2nd line of the signup function he does exactly what you say. But then on line 4 of that function he makes a user variable to push to the DB that exists of again the salt + the hash of salt with password. Im confused why he does it like that
4:35 If I store salt next to the hash in the database, what's stopping the attacker to take that salt and generate a batch of hashes for the most common passwords salted with my salt, and compare them against my hash?
The video doesn't accurately explain why salts are important. The salt doesn't make a single user's password harder to guess. It makes sure that different users with the same password don't end up with the same hash.
If salts are not used, an attacker can simply figure out what the hash for "password123" is, and they instantly know that every single user with that hash is using that password (someone actually did this, I think it was to Adobe).
If you use salts, even if an attacker figures out that one user is using "password123", that doesn't immediately expose any other user's password.
I have this same question
@@leoaso6984 I don't understand this, the attacker knows that they can just remove X number of characters from the front of the hash, then search for that in the database, ignoring those characters at the front?
@@richardtan1332 That won't work because hashing the same password with two different salts gives you two different hashes.
For example, Let's say the hash of '12345' is 'f4cdf537'. Every single user with that password will have that hash in the database. If 10000 users have that hash, then simply decoding that f4cdf537 means 12345 immediately gives a hacker access to 10000 accounts.
Salting prevents this. You add a random string to the password before hashing. So for one user, you hash '12345hdie' to get '1a8fe39c' where the salt is 'hdie'. For another user with the same password, you hash '12345rtxo' to get '4ef2ac97', etc.
This way, even if ten million users have the same password, each one has a completely different hash. Even if a hacker has all the hashes and salts, breaking one password doesn't tell them anything about anyone else's password.
hackers would watch this in reverse
TIL. > with mental model hash = chop & mix, salt make more sense > cryto mining uses thing like scrypt > timing attack > hash vs. encryption
Haha, that challenge was fast
Edit:
Also, adding to the awesome video, cryptography, no matter how strong the math behind it is, if badly implemented will still be vulnerable.
How did you solve it?
@@soumyajitdey5720 check the hash type and then use a well known weakness for those hash. It is quite trivial and it shows the point of salting. Spoiler warning!!!
.
.
.
.
.
.
.
.
.
.
.
It is MD5 without a salt and then you just use a lookup table.
@@YandiBanyu great! Was thinking along the same lines but you were quicker 😂 Good job! 👏
@@soumyajitdey5720 I didn't get the challenge either lol. Watched the vid 6 minute after release and the challenge were already solved.
One day that I encountered an issue with bcrypt that return *different* hash for the same input. It looks contrary to 02:03 . Is the statement wrong? If it correct, can someone explain?
it must be in two parts with more details .
Hi! This is. so cool! How would it be if you guys made a playlist called "Every dev should know"??
"Angular is the best" - Jeff (2nd November 2021)
While I find all Fireship channel's videos useful, this one was especially helpful to me as it allowed me to finally dissolve my chronic confusions about Crypto concepts and gain nice clarity.
I found your use of simple yet concrete hands-on examples, your logically moving from one concept to the other (while comparing and contrasting each), and your use of memorable analogies very helpful.
Thanks for the good work. God bless.
Hello, I'm new to Biticon trade and l've been making huge losses but recently i see a lot of
people earning from it. Please can someone tell me what to do?
@Kelvin Well, you are saying the fact. I invested
$4,000 with Mrs Annabelle Hartfield , and earned $12,000 in 7 working days.
In Bitcoin investment, determination to take risk is one of the major factor required because it takes a
brave heart to make money this days.
Being a newbie in Bitcoin investment and trading is
very discouraging but since I met Mrs Annabelle Hartfield , she has really been careful in handling my investment.
Many people are afraid to be invest because of the Scammers in the business
Yes there are scammers in the business just like it's in every other business but there are also legit brokers out there for investors and Mrs Annabelle Hartfield is one of the real and legit brokers out there.
dude you are awesome, I read a book called Mastering bitcoin and I understood most of this but you just killed it in this short video as always. 🙌🏽
I'm subscribed to a f*ck ton of coding channels but this one is by far my favorite! So straight-forward and highly informative with a visual to complement it! I love how you explain a concept and then will proceed on with various examples as well as implementations. Keep it up bro!
the best IT youtuber ever by far !!
I like how no one in the comments mentioned the "the british are coming!" Reference haha
Pretty sure if he had put “Let’s go Brandon” there would’ve been some response
9:45 is incorrect.
In HTTPS, asymmetric encryption is only used to exchange a key. The key is then used to encrypt all data with symmetric encryption.
I'm so early that the video is in 360p
edit: superhacker
Sa.e
Very good channel with to the point content, spiced up humor! Thanx!
A whole semester saved by this man, thank you brother
Finaly a video in which the half is not clickbaity claims and explaining what the Byte is ❤ Thank you 🙂
So early that it's still 360p
Top tier content. This channel is what I am going to tell people to refer to for any web related knowledge.
You just summarized my 3 month university course into 12 min 😂😂😂. I completely love your videos ❤️
*Error in Video*
Messages longer than public key cannot be encrypted using the public key. This is an *important limitation* to note.
HTTPS performs *key exchange* (using public and private keys to generate symmetric key) and then encrypt any data larger than the public key using the resulting *symmetric key* .
You can encrypt arbitrary long messages with any decent encryption algorithm using any key.
@@lawrencedoliveiro9104 That's incorrect. Try the above to understand the nuanced (but well documented) limitations of RSA mentioned above.
@@vishalmishra3046 Consider that there is no limit on the length of a TLS certificate.
I have a midterm for my IT Security class literally tomorrow, this video came out at the perfect time and was a great little review for me. How does Fireship always know exactly what I want when I want it?
Jeff is a friend of Zucc so he has all of our data and runs a simulation of all of our brains in virtual machines and can thus determine exactly what video everyone wants at any given time.
at 4:55 the constant 'salt' was made calling the randomBytes() method. But if this is a validation script that compares hashes of the provided input and the database contents, and the script runs multiple times, isn't that gonna change the salt every time the script is called? randomBytes() as I believe generates different values every time the script is ran so the salt is gonna be different and the comparison will fail as the hashes will change with the salt am I right?
I also was a bit confused by this bit. Following.
idk if my previous comment went through (could be flagged as spam for including a link to my own blog) so in case it didn't get through, I'll give the gist of it:
Basically you store *everything* needed to verify the hash with the hash (with the exception of the password itself obviously).
This includes:
- The algorithm used (or preferably some kind of reference to it for better backwards compatibility - in case the recommended algorithm changes, so you don't break non-updated passwords).
- The salt used.
- The "cost" (basically how often one runs the output hash through the algorithm again).
- The hash itself.
Then to verify the hash, you basically do exactly the same as you did to obtain the hash (which you can all find in the data you stored with the hash) and check whether the output is the same.
Note that the signup function is called once, and the random salt is created and stored in the database. Then at login, the salt for that specific user is retrieved in order to be able to verify the hash of the (salt + provided password), matches the database stored hash.
@@MINDoSOFT exactly what I was thinking of that the salt is actually stored with each user's information in the database. But actually that is a flaw if you think about it. the whole idea of salting is that to make the credentials harder to crack once dumped from a database. But if the salt is in the database also, it will be exposed and it will be useless as the attacker crack them with the salt. So I guess the best bet is to store the salt as a constant inside the file or maybe store these random salts in a separate database.
@@FinlayDaG33k Thank you for that but my question wasn't about the hashing process, sorry for that. I was actually asking about a potential bug in the code. He used a method that generates a random salt each time a user registres his/her credentials. But what if the server needs to validate those credentials in later time? The server will not know what is the salt used with the specific user's creds as the random method generates a different salt each time it is called (The script is ran). So my question is what is the solution to that? I explained in the previous comment why storing these salts with the user's creds in the database is completely useless, so what is the solution?
Hmmm, That was a lot to "digest"
Great job on this video. Really awesome. I love the challenge at the end. Great content! Thank you for sharing.
You know you're among the first viewers when you have to watch it in 360p lol 😂
I really love every single video you post, they're so useful but this one... Wow!
Thanks for sharing your knowledge 🤙🏼
You forget main technology of widely used by both government agents and theirs not so legal opponents for decryption. Thermorectal cryptanalysis is very effective, fast, eco-friendly (because it uses really energy efficient hardware, 50 watt decription device is powerful than enough for most situations) and required relatively low qualification for operators.
What are u talking about? Xd
Haha thermorectal, all your secrets belong to us 😂
I usually see this kind comments on fireship and laugh but now I can't believe I'm leaving it too "I really needed this video and fireship made it"
This is one of your best videos, hands down. Thanks for sharing Jeff!
3:11 MD5 Hash.
People in cryptography got a good laugh at that. Thank You for the smile and laugh.
One great book about cryptography and steganography (similar techniques to the bald guy moment) is "The Code Book" by Simon Lehna Singh. Highly recommend it as it explains the evolution of this "math thing" from the beginning to our days in a very intuitive and easy-to-understand way.
Not essential, but also important/useful:
- password hashes / key derivation
- secure randomness
- encrypting a single bit
- non-malleable encryption
- homomorphic encryption
- key exchange
- deniable encryption
- zero knowledge
- commitment?
Nice vid 🔥
But I can’t get one thing. Why did you use fixed separator (:) for storing hash and salt? Isn’t it oblivious for the attacker which part is what. Mb better option will be to use fixed length?
Sure it is oblivious. But to generate the resulting hash, you need to add the salt. This means that a password if hashed (say "abc") will be the result of "abc"+salt. Now if each user has unique salt, it means lookup table attack is pointless and the hacker need to attack each hash independently.
@@YandiBanyu and i believed all the time, we should not save Salt in the DB. Just have it in the Application Ram. So if the Database lost. the Salt is independent..
@@mikelinsi Well, the problem with that is, if you have an upgrade to your application, those salt are lost. Remember, to check the password you need the salt and then hash them then compare the result. Without salt, you cannot check the user anymore. Also, you should use different salt for each user.
It was used as an example. One should use fixed size salts for the reason you showed.
It's just a technical detail. If the salt and password lengths are constant, a separator wouldn't be needed. Or they could even be stored in different columns. Doesn't really matter. Also, if using a single field that combines the salt and the hash, trying to depending on an attacker not knowing where in the field the divide is would be a type of security-by-obscurity, which doesn't work anyway, so you might as well put the separator there, for your own convenience.
The hash at 11:40 is written in the next comment, as to no spoil it for anyone that want to try and find it themselves.
I'm actually tired of worrying about stocks...it's driving me nuts these days,I think crypto investment is far better than stock..
Stocks are good but crypto is more profitable
I'm new to forex trade and I have been making huge losses but recently see a lot of people earning from it.can someone please tell me what I'm doing wrong
@@evelynhannah3147 All you need now is a professional broker else you gonna continue blowing of your account
Mr Dennis services is working for me at the moment and am making good profits from forex and crypto trading.
@@jeremysanchez5545
Same here, it’s four months now I started investing with him and it's been good experience
The mailbox analogy for public/private key is quite brilliant! Good job
6:47 THE BRITISH ARE COMING
Nice video, it covers a lot of really important topics in a easy to understand way
It‘s easier to understand the concept of public key, when it is represented with a padlock symbol, rather than a key.
The private key then unlocks the closed padlock.
I am so happy to see this video after the great API video that had the big MD5 problem ;)