It's his enthusiasm that does the trick! I'm absolutely caught up in his speech, unable to stop listening, getting angry at the video ending so abruptly!
I took the Computer Security Module and audited the Cryptography modules this year at the university of nottingham, both of which were taught by Dr Mike Pound, and honestly it was amazing. He has a great way of explaining hard concepts in a way that's easy to understand.
....I honestly get the feeling that Dr. Pound is wildly more intelligent that we realize or he portrays and he always seems like he has to hold back just a bit so he doesn't inadvertently say too much. Like, there is a line that shouldn't be crossed with regard to explaining things and he is constantly dancing with that line and at times has to stop for a moment and think "Ok, right, where am I?....oh, right, ok we can go further" lol Anyone else get that?? Hes awesome man.
The seccond method can actually be just as secure if it is guaranteed that none of the valid messages can be a simple concatenation of 2 or more other valid messages. The easiest way to guarantee it is just to always put a total message length block somewhere inside the protected message. This method is a little bit faster than the HMAC.
Love this series, but could you please cover Elliptic curve Cryptography? I feel like this channel explains everything the best, so it would be much appreciated.
He's the archetype for the perfect teacher to engage students in learning. He combines easy grasped examples with technical concepts and makes even very complex subjects easily understandable even to a slightly learned layman.
I feel like these videos always just scratch the surface and don't go in depth too often. I really would like to see some in depth content for the loyal subscribers!
Dr. Mike is the best! And this totally reminds me of the Office, especially with the personal interviewing and the random zooms and close-ups 😂 I also love the washing machine animation!!
I have a big ask. It may take several videos but I should love to see a simple but complete differential cryptanalysis. And a set on linear cryptanalysis. We hear about it all the time but it means very little to most of us. There are many books on it but these are hard to follow, a video would be much easier and better. Thanks! If you do it I shall sent a much bigger 'thank you', capital letters and all!
I like the videos that Dr. Pound does on cryptography and cryptoanalytics, but it would be nice if he could get into more of how the math works behind the concepts. Not just describe the variables.
Great video! Can you also do one talking about HMAC-before-encrypt vs encrypt-before-HMAC? encrypt(message)|hmac(key,encrypt(message)) vs encrypt(message|hmac(key,message))
Something I didn't understand. Around 5:00, after introducing the first "naive" solution to the problem of tampering the stream cipher - i.e. computing a hash - Dr. Mike rejects this immediately because the middle-man can easily tamper the message and then compute a hash. what I don't understand is how can he compute the hash of the unencrypted message? All he has is the encrypted message, and if the hash is of the un-encrypted, how can he compute this?
You say hases aren't for disks, but I'm pretty sure full disk encryption needs to have something like that... I remember hmacs being mentioned in the WiiU external drive encryption scheme...
Someone just flipping bits like that doesn't have the old message or the new message to compute the hashes from. Plus the hash itself is likely to be encrypted. Here, it comes down to how much power you think the attacker has. If he can read all your messages and correctly guess all your keys, you're sunk anyway because he can do whatever he wants.
it's still useful to ensure by construction that the code that reads these messages can't accidentally reveal any information (for example side channel or timing attacks could play into this), or be made to crash given tampered data, naive tamper resistance schemes do not necessarily meet these criteria even if they exclude tampering per se
what exactly stops us from doing h(m|k) as opposed to h(k|m)? we don't need to worry about resuming the internal state of the hash function because that would only allow us to append to the key, not the message
So, the outerpad and innerpad are just arbitrary constants that are used to derive the two separate keys which are then used to hash the message authentication code?
I was just writing in the middle of writing an RFC6238 TOTP in C++ (because I can't find any that compile in Code::Blocks to run in cmd.exe. Obviously over on Linux its all just works.)
why not just append a salt and signature of the message+salt after that BEFORE applying the cipherstream? The attacker could change the message, but they're going to have a pretty hard time guessing what the salt is to compute the hash and even if they did they wouldn't be able to XOR it to the state the recipient expects.
I've really enjoyed these videos that are related to information and security! I was wondering though, could you guys could make some videos in the "Essentials" series that cover the basics of those topics?
Unfortunately it's a broad subject, and modern cryptography (elliptic curves, for example) has really changed a lot of what is considered "essential" compared to a few years ago. There are some great courses on youtube, but that's literally tens of hours of material...
I think in the video, we were shown this as a non-working solution: encrypt(message)|hash(encrypt(message)) Why couldn't you do this: encrypt(message|hash(message))
From 6:10 to 6:42 I got completely lost. I didn't understand what you were talking about and also couldn't make out some words. Could somebody explain it to me or just point me to the video I missed to understand that?
The Merkle-Damgard construction is a way of taking what's called a compression function, which has nothing to do with compression like zip files - that takes two blocks of constant length and produces one block of constant length that is a "mix" of the two inputs, and extends it to any message length by splitting the message into blocks, and chaining the blocks together, so you "compress" an initialization vector with the first block, and then take the output of that and the next block and "compress" that... Since the final hash is output of the last compression operation, if you know the hash of a message, you can produce the hash of any of its suffixes, even if you don't know the original message. Using his example, you could add additional 0s to the amount, instead of changing the most significant digit, even if it was prefixed with a key. By adding another hashing step that also depends on the key, you can prevent this kind of tampering, which is known as a length extension attakc.
Why we just hash before encrypt all together message and hash? we could not compute a new hash for the changed message since we would need to know the encryption key
could you hash the message and append the hash before encrypting it and then verifying i after decryption, or are there any security implications that make that a bad idea?
Is this part of a series? He mentions the SHA video as if I'm supposed to have seen it before, but I can't find an official playlist with computer security related videos från computerphile.
If we insert the hash (k1|m) at the start of message itself won't it also solve the problem? May be it s not efficient to prepend than append but i think it'l also solve the problem, but i would like to know your opinion
Why not just do SHA2( msg | key ) and not SHA2( key | msg ) like this the malicious appends can only get SHA2( msg | key | malicious ) but the check will be made SHA2( msg | malicious | key) ?
Why not just append the key to the end of the message before taking the hash instead of prepending it to the beginning? Wouldn't that solve length-extension?
It does, but I think the intent was to secure an arbitrary message without requiring knowledge of what cypher it was using. Other people could bit flip all they want but unless they can decode the stream in the first place they can't correctly re-encode a new hash.
It makes you vulnerable to padding oracle and other chosen ciphertext attacks. That construction is called MAC then Encrypt, and is insecure if the encryption scheme is vulnerable to such attacks (many are, and are designed to use a MAC of the ciphertext to remove the vulnerability).
this is worse than MAC-then-encrypt, since the hash isn't signed, a chosen plaintext attack will also allow forgery, for stream ciphers and non chaining block cipher modes: You choose m_1, and get c_1: c_1 = k_1 ^ (m_1 || H(m_1)) You can recover the key stream (but not with a chaining block cipher mode): k_1 = c_1 ^ (m_1 || H(m_1)) Forge ciphertext for arbitrary message m_2: c_2 = k_1 ^ (m_2 || H(m_2)) In other words, the hash only provides integrity checking, not authentication
If I create a hash of the message and append that to the end of the message and stream cypher the whole bytes stream (message + hash) it will make things harder to change the message.
Wait a sec? So a Block cipher changes multiple bits? so if I changed a single letter/bit, in the message that in turn makes the entire message of letters before and after get altered also??? I know of alot of coding systems but as far as I'm aware I think everything usually is 1 to 1, example if we used Enigma 1 letter in 1 letter out sorta like a substitution! If we Transposition it then the same amount of letters move around, If we playfair it then we still end up with same count of letters, in fact I can't think of any 1 situation where 1 plaintext letter is fully responsible for keeping the entire rest of the message mathematically in tact The only thing I can think of is... if you Take 8 Letters that are 8 Bits long in Ascii and Put the rows of numbers 1 by 1 under until you get like 8x8 thus 64 bits but instead grouping all the 1st bits and making an Ascii character out of then then all the 2nd bits until all 8 is done then substitute that maybe along with a 1 time pad, then I can see how maybe by chance changing 1 Ascii can sometimes Affect many characters, unless I'm not seeing something here? So example lets say A=001 B=010 C=100 R=111and our word was Cab then 100, 001, 010 if stacked could be 100, 001, 010 which doesn't change anything but lets try BAR, 010, 001, 111 we get now, 001, 101, 011 now this is kinda neat because we have new numbers which might be mapped to a question mark or something if this was 8 bit ascii but then math to it could change it yet again. I can't 100% see how a single change normally can affect the outcome of how a message works, but I can see in my example how sometimes hit or miss it can affect the entire message! I will have to look at block ciphers to maybe understand, but for most part from my experience the bulk of codes/encryption almost always is the Plain Text being heavily altered with some steps where if you isolated any letter usually, you get the plaintext of that specific letter! Equally speaking if deleting a letter anywhere or changing a letter anywhere also usually doesn't disturb a message most times in all of it's entirety. However what I can say is... if it is possible where 1 Letter is the only way to crack the code if unchanged and all characters have that exact same property and must be One! Then yes that would be 100% valuable and secure as you can just take that and put that through 1 to 1 ciphers knowing there was a step involved that binds all of them together as a whole as one unit.
Both are used. However, the new consensus is to encrypt then hmac. It allows you to skip decryption when the hmac is invalid. Thus allowing you to break earlier in your algorithm, resulting in less implementation mistakes. For example with block ciphers it might still be possible to exploit a padding oracle if the attacker can distinguish between the decryption failing and the hmac check failing, which in the case of never touching the encrypted text can never happen.
if you use a random ID, you need to keep track of what it's identifying, which means you need to store that data, and storage scales as the number of things you need to keep track of. Using an authenticated encryption lets you delegate the storage to an untrusted party, without revealing the contents and without compromising your trust in the data, and only need to store a small amount of unchanging data.
Check out Joanna Rutowska's talks and paper on the x86 architecture... However, I don't think you can cover this in any meaningful way in a short video, Qubes is mostly about deconstructing the problems in personal computing that trace back to bad design decisions and assumptions, and it tries to mitigate risks. To explain what it does you need a lot of understanding of the mechanics of the things it relies on, as well as an understanding of why the normal way is a bit broken. If you want to ask questions I'd be happy to answer what I know, but I don't think you will find easy answers in this format
Right. Thanks! English pronunciation/spelling is weird. However, I always felt that guests on the show should be showcased more, nobody reads the description. I'll blame it on that! :-(
seeing as apple stole the brand iPhone from another company, more or less, this should really help the conspiracy theorists make a compelling argument, since it'll be that much harder to google =)
You also need to handle deleting a message [Alice says pay Bob £100] Alice might want to remove that message. Equally Alice might want to add a message saying Bob to pay Alice £100
merkle proofs are useful for confirming the existence of a message, but proving a message did not exist requires something like a blockchain or a trusted third party
I want to meet this man. I feel like I could hear him talking from hours and not get bored.
@urbex2007 I guess it's supposed to be that way. He never looks directly into the camera, he looks towards the hidden interviewer instead.
It's his enthusiasm that does the trick! I'm absolutely caught up in his speech, unable to stop listening, getting angry at the video ending so abruptly!
You can say that again
I took the Computer Security Module and audited the Cryptography modules this year at the university of nottingham, both of which were taught by Dr Mike Pound, and honestly it was amazing. He has a great way of explaining hard concepts in a way that's easy to understand.
I'd love to meet this man too huge respect for Mike pound :)
This bloke is a well-rounded pundit of computer science--vision, cryptography, algorithms, all the good stuff.
....I honestly get the feeling that Dr. Pound is wildly more intelligent that we realize or he portrays and he always seems like he has to hold back just a bit so he doesn't inadvertently say too much. Like, there is a line that shouldn't be crossed with regard to explaining things and he is constantly dancing with that line and at times has to stop for a moment and think "Ok, right, where am I?....oh, right, ok we can go further" lol
Anyone else get that??
Hes awesome man.
Brian Streufert what? He is obviously very intelligent, else he wouldnt have doctorate.
Nooo....beyond that level even!
Brian Streufert what level do you mean? Omnipotent/supernatural level?
Would you say that you find his intelligence artificial?
I get what you mean. Hopefully like Robert Miles he starts his own channel
Dr. Pound! This guy could read me his shopping list and I would still watch it
I'm sure he would manage to make it hilarious :)
Please sent Mike £100
Sneeze bent like 7FFF
Thank you Please!
He wants it yesterday !
Please sent Mike £100 yesterday
Please send Mike £100 today
Plase send Mike £10M
Absolutely love these computerphile videos. To the team: please do not stop making more videos!
The encryption related Computerphile videos are some of my favorite.
make a 2 hour video with this guy, i could listen to him all day
HE'S BACK! ALL ABOARD THE TRAIN TO POUND TOWN...
This guy is my favorite!
Great video. I love Mike Pound - he is my favorite person on computerphile
Just wait until you meet Mike Hawk
Well, do not forget AES CBC is weird, it’s a block cipher, though because of the XOR chaining you can also do this there
Switching off is probably not what anyone has ever done that clicked on a Computerphile video, especially with Mike.😁
The seccond method can actually be just as secure if it is guaranteed that none of the valid messages can be a simple concatenation of 2 or more other valid messages. The easiest way to guarantee it is just to always put a total message length block somewhere inside the protected message. This method is a little bit faster than the HMAC.
I didn't even know HMACs existed until I came across them at work - it's good to know a bit more about them.
I have an exam in computer security coming up soon. These videos are golden
Love this series, but could you please cover Elliptic curve Cryptography? I feel like this channel explains everything the best, so it would be much appreciated.
djb and Tanja Lange have a great intro to the subject from 31c3
@@foobargorch Thanks for that!
Someday you should do a video on AEAD, which is more modern than plain old Stream cipher.
its said if you can explain something in simple words, you dont understand the concept. But you sir are just a marvel. Thanks alot.
Is it wrong to feel kinda in love with him? I might have completed my studies if he were my teacher.
He's the archetype for the perfect teacher to engage students in learning. He combines easy grasped examples with technical concepts and makes even very complex subjects easily understandable even to a slightly learned layman.
I feel like these videos always just scratch the surface and don't go in depth too often. I really would like to see some in depth content for the loyal subscribers!
Mike is implicitly asking us to send him £100
£900 *
Sent*
just had an hmac nightmare, this came a bit too late
This video seemed to end without much of a conclusion...
I like the way how he comes to the topic, it's brilliant Mike!!!!
You're helping me so much studying for my Security+ exam!!!!
How are you able to explain topics so easily.Seriously, it seems like child's play when I understand things like this
Dr. Mike is the best! And this totally reminds me of the Office, especially with the personal interviewing and the random zooms and close-ups 😂 I also love the washing machine animation!!
This is the most amazingly clear and concise explanation, thanks
This guy is awesome. Make sure he keeps on making us videos!
I freaking love this dude. Why aint this guy my teacher.
Should have watched this video before my midterm...finally I feel like I know something. Thanks!
Thanks. Studying for CISSP. I just subscribed!
I like the void cube and ghost cube on the shelf. :D
😏 Ghost Cube has finally been solved 🙌
I have a big ask. It may take several videos but I should love to see a simple but complete differential cryptanalysis. And a set on linear cryptanalysis. We hear about it all the time but it means very little to most of us. There are many books on it but these are hard to follow, a video would be much easier and better. Thanks! If you do it I shall sent a much bigger 'thank you', capital letters and all!
these guys are legends
thanks a lot this helped me in studying hmac for my exams
I like the videos that Dr. Pound does on cryptography and cryptoanalytics, but it would be nice if he could get into more of how the math works behind the concepts. Not just describe the variables.
5:13 But why don't we encrypt the checksum too? In other words be append hash of the message right *before* we do the encryption
I’d love to know the reason too
0:53
Left upper corner, that ghost cube :D
Very few understand this.
Great video! Can you also do one talking about HMAC-before-encrypt vs encrypt-before-HMAC? encrypt(message)|hmac(key,encrypt(message)) vs encrypt(message|hmac(key,message))
Confidentiality isn't the objective of HMAC, so encrypting the final message doesn't make sense. HMAC provides authentication and integrity
@@hardikmaru3311 You would want to encrypt then HMAC the encrypted message. Also known EtA
Something I didn't understand. Around 5:00, after introducing the first "naive" solution to the problem of tampering the stream cipher - i.e. computing a hash - Dr. Mike rejects this immediately because the middle-man can easily tamper the message and then compute a hash. what I don't understand is how can he compute the hash of the unencrypted message? All he has is the encrypted message, and if the hash is of the un-encrypted, how can he compute this?
I don’t understand either. Also if you send the hash encrypted too, there would in my mind absolutely be no way to reconstruct it
Gotta love the paper he uses with the sprocket holes. Who does that ?!?! LoL
idk why but this reminds me of the office
Hash length extension attack video ?
The teaching is awesome and he explains greatly, but i can't help but to notice how every video seems like an episode from The Office
What about video encryption is this stream cypher?
Well done ! really enjoyed your video.
You say hases aren't for disks, but I'm pretty sure full disk encryption needs to have something like that...
I remember hmacs being mentioned in the WiiU external drive encryption scheme...
Someone just flipping bits like that doesn't have the old message or the new message to compute the hashes from. Plus the hash itself is likely to be encrypted.
Here, it comes down to how much power you think the attacker has. If he can read all your messages and correctly guess all your keys, you're sunk anyway because he can do whatever he wants.
it's still useful to ensure by construction that the code that reads these messages can't accidentally reveal any information (for example side channel or timing attacks could play into this), or be made to crash given tampered data, naive tamper resistance schemes do not necessarily meet these criteria even if they exclude tampering per se
YAY he finally solved the ghost cube
06:33 would adding length of message (excluding added length) in message prevent append attack?
what exactly stops us from doing h(m|k) as opposed to h(k|m)? we don't need to worry about resuming the internal state of the hash function because that would only allow us to append to the key, not the message
How do the sender and receiver get same key? Do they use key exchange protocols?
So, the outerpad and innerpad are just arbitrary constants that are used to derive the two separate keys which are then used to hash the message authentication code?
Helps me study for CISSP, thanks!
I was just writing in the middle of writing an RFC6238 TOTP in C++ (because I can't find any that compile in Code::Blocks to run in cmd.exe. Obviously over on Linux its all just works.)
This guy couldn't look any more mischievous if he wore a black henchman's mask befitting a 70s' Batman episode.
thank you for that brilliant video!
There is a guy named Please who pleases Mike.
Anyways, what is special about CMAC and Poly1305?
why not just append a salt and signature of the message+salt after that BEFORE applying the cipherstream? The attacker could change the message, but they're going to have a pretty hard time guessing what the salt is to compute the hash and even if they did they wouldn't be able to XOR it to the state the recipient expects.
I've really enjoyed these videos that are related to information and security!
I was wondering though, could you guys could make some videos in the "Essentials" series that cover the basics of those topics?
Unfortunately it's a broad subject, and modern cryptography (elliptic curves, for example) has really changed a lot of what is considered "essential" compared to a few years ago.
There are some great courses on youtube, but that's literally tens of hours of material...
Actual HMAC stuff starts at 4:00
Until then, he's pointing out flaws with substitution in a stream cipher.
I think in the video, we were shown this as a non-working solution: encrypt(message)|hash(encrypt(message))
Why couldn't you do this: encrypt(message|hash(message))
that's essentially what signing is, you take checksum and encrypt it with the private key - and what you get is a signature.
but both keys are private...
Greg Jaskiewicz j
Greg Jaskiewicz o
Christopher Smith, yes, I was definitely missing an explanation for why that is a bad idea!
From 6:10 to 6:42 I got completely lost. I didn't understand what you were talking about and also couldn't make out some words. Could somebody explain it to me or just point me to the video I missed to understand that?
The Merkle-Damgard construction is a way of taking what's called a compression function, which has nothing to do with compression like zip files - that takes two blocks of constant length and produces one block of constant length that is a "mix" of the two inputs, and extends it to any message length by splitting the message into blocks, and chaining the blocks together, so you "compress" an initialization vector with the first block, and then take the output of that and the next block and "compress" that...
Since the final hash is output of the last compression operation, if you know the hash of a message, you can produce the hash of any of its suffixes, even if you don't know the original message.
Using his example, you could add additional 0s to the amount, instead of changing the most significant digit, even if it was prefixed with a key.
By adding another hashing step that also depends on the key, you can prevent this kind of tampering, which is known as a length extension attakc.
Why we just hash before encrypt all together message and hash? we could not compute a new hash for the changed message since we would need to know the encryption key
*Sees doc pound*
*EXTERMINES THAT LIKE BUTTON*
could you hash the message and append the hash before encrypting it and then verifying i after decryption, or are there any security implications that make that a bad idea?
There's no video about the length extension attack yet if i see right :(
Is this part of a series? He mentions the SHA video as if I'm supposed to have seen it before, but I can't find an official playlist with computer security related videos från computerphile.
need more !!!
Thank you!
DONT QUIT THE VIDEO JUST YET 😂
So I guess the length extension video never came out sed.
so why not just use digital signatures? when would we use HMAC as oppsed to using signtures?
The captions on this aren''t great, any way for me to edit?
If we insert the hash (k1|m) at the start of message itself won't it also solve the problem?
May be it s not efficient to prepend than append but i think it'l also solve the problem, but i would like to know your opinion
"We can actually change the amount get sent, which unfortunately is a purely hypothetical example, I don't actually get any money" 😂
Does anyone know, what's inner pad and outer pad which he mentions at 8:10?
Why not just do SHA2( msg | key ) and not SHA2( key | msg ) like this the malicious appends can only get SHA2( msg | key | malicious ) but the check will be made SHA2( msg | malicious | key) ?
Doc Pound is my jam
Why not just append the key to the end of the message before taking the hash instead of prepending it to the beginning? Wouldn't that solve length-extension?
Why doesnt this work?:
encrypt(message hash(message))
well, it does work.
It does, but I think the intent was to secure an arbitrary message without requiring knowledge of what cypher it was using. Other people could bit flip all they want but unless they can decode the stream in the first place they can't correctly re-encode a new hash.
It's a stream cipher, so you shouldn't be able to hash the whole message ? (I think)
It makes you vulnerable to padding oracle and other chosen ciphertext attacks. That construction is called MAC then Encrypt, and is insecure if the encryption scheme is vulnerable to such attacks (many are, and are designed to use a MAC of the ciphertext to remove the vulnerability).
this is worse than MAC-then-encrypt, since the hash isn't signed, a chosen plaintext attack will also allow forgery, for stream ciphers and non chaining block cipher modes:
You choose m_1, and get c_1:
c_1 = k_1 ^ (m_1 || H(m_1))
You can recover the key stream (but not with a chaining block cipher mode):
k_1 = c_1 ^ (m_1 || H(m_1))
Forge ciphertext for arbitrary message m_2:
c_2 = k_1 ^ (m_2 || H(m_2))
In other words, the hash only provides integrity checking, not authentication
You can see at 5:44 the spider bite in Tobey Maguire's hand
I'm a newbie, is hmac reversible?
If I create a hash of the message and append that to the end of the message and stream cypher the whole bytes stream (message + hash) it will make things harder to change the message.
It's David Brent!!!
Wait a sec? So a Block cipher changes multiple bits? so if I changed a single letter/bit, in the message that in turn makes the entire message of letters before and after get altered also??? I know of alot of coding systems but as far as I'm aware I think everything usually is 1 to 1, example if we used Enigma 1 letter in 1 letter out sorta like a substitution! If we Transposition it then the same amount of letters move around, If we playfair it then we still end up with same count of letters, in fact I can't think of any 1 situation where 1 plaintext letter is fully responsible for keeping the entire rest of the message mathematically in tact The only thing I can think of is... if you Take 8 Letters that are 8 Bits long in Ascii and Put the rows of numbers 1 by 1 under until you get like 8x8 thus 64 bits but instead grouping all the 1st bits and making an Ascii character out of then then all the 2nd bits until all 8 is done then substitute that maybe along with a 1 time pad, then I can see how maybe by chance changing 1 Ascii can sometimes Affect many characters, unless I'm not seeing something here? So example lets say A=001 B=010 C=100 R=111and our word was Cab then 100, 001, 010 if stacked could be 100, 001, 010 which doesn't change anything but lets try BAR, 010, 001, 111 we get now, 001, 101, 011 now this is kinda neat because we have new numbers which might be mapped to a question mark or something if this was 8 bit ascii but then math to it could change it yet again. I can't 100% see how a single change normally can affect the outcome of how a message works, but I can see in my example how sometimes hit or miss it can affect the entire message! I will have to look at block ciphers to maybe understand, but for most part from my experience the bulk of codes/encryption almost always is the Plain Text being heavily altered with some steps where if you isolated any letter usually, you get the plaintext of that specific letter! Equally speaking if deleting a letter anywhere or changing a letter anywhere also usually doesn't disturb a message most times in all of it's entirety. However what I can say is... if it is possible where 1 Letter is the only way to crack the code if unchanged and all characters have that exact same property and must be One! Then yes that would be 100% valuable and secure as you can just take that and put that through 1 to 1 ciphers knowing there was a step involved that binds all of them together as a whole as one unit.
CBC mode for block ciphers
So... do you HMAC then encrypt or encrypt then HMAC? And for the love of Turing, please clean your screen. :)
IIRC, both are valid approaches and both are used in practice.
Both are used. However, the new consensus is to encrypt then hmac. It allows you to skip decryption when the hmac is invalid. Thus allowing you to break earlier in your algorithm, resulting in less implementation mistakes. For example with block ciphers it might still be possible to exploit a padding oracle if the attacker can distinguish between the decryption failing and the hmac check failing, which in the case of never touching the encrypted text can never happen.
if you use a random ID, you need to keep track of what it's identifying, which means you need to store that data, and storage scales as the number of things you need to keep track of. Using an authenticated encryption lets you delegate the storage to an untrusted party, without revealing the contents and without compromising your trust in the data, and only need to store a small amount of unchanging data.
The questions of the guy with the camera don't sound very clearly..
Did i miss something or he never mention how we gonna send the shared secret key to the other person ?
Why do I get the feel that this guy was a car mechanic in a previous life?
But how would you share the key in secure way?
Vinicius Macelai Look up Diffie-Hellman key exchange
Mike, could you please cover Qubes OS? :)
Check out Joanna Rutowska's talks and paper on the x86 architecture... However, I don't think you can cover this in any meaningful way in a short video, Qubes is mostly about deconstructing the problems in personal computing that trace back to bad design decisions and assumptions, and it tries to mitigate risks. To explain what it does you need a lot of understanding of the mechanics of the things it relies on, as well as an understanding of why the normal way is a bit broken.
If you want to ask questions I'd be happy to answer what I know, but I don't think you will find easy answers in this format
Whose videos are referenced in the bit about hamming distance at 8:50, Dave Brelson is the best I can make out...
+George-Cristian Bîrzan Professor Dave Brailsford has done a number of computerphile videos regarding hamming codes
Right. Thanks! English pronunciation/spelling is weird.
However, I always felt that guests on the show should be showcased more, nobody reads the description. I'll blame it on that! :-(
Psuedo?
iPad, mac, illuminati
The iLluminati is the new smart-bulb by Apple I guess :D
seeing as apple stole the brand iPhone from another company, more or less, this should really help the conspiracy theorists make a compelling argument, since it'll be that much harder to google =)
is it just me or are they spelling "pseudo" as "psuedo"?
+lonerboy013 I thought that didn't quite look right! Should've checked! >Sean
You also need to handle deleting a message [Alice says pay Bob £100] Alice might want to remove that message.
Equally Alice might want to add a message saying Bob to pay Alice £100
merkle proofs are useful for confirming the existence of a message, but proving a message did not exist requires something like a blockchain or a trusted third party