Modes of Operation - Computerphile
Vložit
- čas přidán 11. 06. 2024
- You don't just 'run a cipher' - you need a mode of operation. Dr Mike Pound explains some relative to the Feistel cipher.
*This video was filmed before any social distancing guidelines came into effect*
EXTRA BITS: • EXTRA BITS: Feistel Mo...
Feistel Cipher Video: • Feistel Cipher - Compu...
Mike's code:
github.com/mikepound/feistel
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computer Science at the University of Nottingham: bit.ly/nottscomputer
Computerphile is a sister project to Brady Haran's Numberphile. More at www.bradyharan.com
More. Mike. Pound.
100 agree
There's never enough Mike Pound.
someone has listened to the podcast. :)
I legit read that as "More Mike Pondsmith" for a second...
guess I've been playing to much Cyberpunk 2077
I was gonna like your comment but it has 420 likes so I'm not allowed
I like how Dr. Pound says “woight” after explaining something.
Please refer to Tom Scott's video called "Why Jonathan Ross Can't Pronounce His Rs"
@@gooball2005 Seems to have become epidemic in the UK in recent times. Everyone's gonna sound like a brit Elmer Fudd eventually.
Right. Why keep do they keep the CC inactive?
tbh i hear the "r" in "right" pretty clearly
@@mos6507 That and pronouncing 'th' as 'f' seems to be common too
“ECB, almost never” unless you’re Zoom...
Philipp Blum not only did they, they still do. AES-GCM is due to be released soon apparently but they have no clue when it comes to security. At least they brought on a bunch of people who do know a lot security to help them out very quickly.
That, and the fact that their “end-to-end” encryption wasn’t end-to-end at all, it was end-to-middle, middle-to-end.
They were also criticized for using AES-128 instead of AES-256, but really AES-128 is fine.
@@PhilippBlum Now it is. Used be not.
Ok zoomer.
@@enochliu8316 Skype was always encrypted end to end with them being p2p in the beginning (with caveats). When MS bought them they switched from p2p to server and also gave state perpetrators wide access to the network.
Excellent presentation - Mike always does a great job of explaining his ideas!!
6:44 "If I'm watching a streaming movie, and I've decided the first half is pretty boring, I want to jump through, so you can't do that because you got to chug through the decryption of everything first" - Actually, while *encryption* of CBC is serial, *decryption* of CBC can be parallelized, you don't need any previously plaintext data, just the ciphertext.
8:57 "And we don't want that weird attack where you fiddle about with ciphertext and it effects other message blocks". Counter mode (without a MAC) is even more attackable by fiddling with the cipher text. For CBC, you get one plaintext block modified (bit-flipped) exactly as you wish, and one block garbled, for CTR (as explained in 11:40) you just get all your bits flipped around (just as for any XOR stream cipher), without anything else affected - so it's a an a lot less noticeable attack. So this is not really an argument for counter mode. If you use a MAC (on the ciphertext) with CBC, it's also pretty save against those attacks. (The other arguments for counter mode are better.)
Thanks, I had the same thoughts as I watched the video and was hoping to find a comment that would confirm them.
Don't you still need to XOR the result of decryption with the previous block's plaintext in CBC?
@@jackawalmsley No, you XOR it with the last ciphertext block, without having to decrypt it.
@@BBeret ahh I didn't catch that thanks
In the first f****** minute I learned more of encryption than in hours of lessons at the uni.
Thank you Mike, you make it easy for learnes to understand the topics and what it's all about!
Next video on Galois Fields lets go!
Ok, that nonce thing caught me off guard cos that's not what it means in British slang...
Mike does such a clear and great job explaining cryptographic definitons! I always enjoy the videos of this field!
Writing a university exam about encryption on Monday. This is the perfect for a video like this 👍
Nice, I'd love a video with more detail about how this Galois counter mode works, as well as detail about the other AES modes like CFB and OFB.
I spent a whole day reading my textbook and listening to my professor's video lecture yesterday and couldn't understand what the heck were the functions of the modes because it was all given to me without diagrams. After watching this video, it makes it simpler for me to understand! Holy smokes!
Even on the internet it is addressed like this. It makes it difficult to conceptualize.
exactly what i need for my course on network security! great as always
Quote from Github: "I've paid absolutely no attention to safe memory use, cache timings etc. So it's conceivable that the cipher is vulnerable while it's running - possibly after too since it doesn't wipe the key from memory."
Python has design issues that makes it hard to stamp those out anyway, though it's feasible to mend _some_ of those problems. In the end, the question remains: Can you trust the hardware your code is running on, and is it sufficient that some parts of the code is still visible to that hardware, or to its operating system. If those things do not pose a problem for you, then cryptography with Python is probably ok for _your_ use case. That isn't to say that it should ever be implemented in a bigger corporation, or on hardware that is exposed to the public.
I've been working on this today with my RCSOTP (random character set one time pad) program. Then I came on YT and saw this vid !!!! Nice one, good vid, all helps.
Do you use it for letter or E-Mail encryption or for other applications (authentication of persons, access, messages, ...)?
@@AnoNymInvestor It can be used for all of those. The encrypted text can also be embedded into the TRGB of glyphs from special fonts that have been used to create a picture (Not at pixel level but at glyph level).
WOW! thanks for the simplified explanations, makes it easy to understand.
Ah, so it's the counter mode that LoRaWAN uses. I've implemented that protocol myself before.
It uses some ECB code to do it. And at the time I was reading up on it what the different modes meant. I was a bit confused why LoRaWAN, generally considered a secure protocol, would use ECB. Then I found out what it was actually doing and thought it was quite smart.
Today I've learnt that it actually has a name! Cool :D
Cool name.
Liked the video, and I'm looking forward to hearing about the GCM mode of operation next time. Are you going to continue after that with AEAD ciphers?
Please make an extra bits or so on GCM and how it works/ benefits :) Awesome video!
Why in CBC can't you continue decrypting from the middle? You just take Cn+1 decrypt it and XOR it with Cn. Was there some simplification in the video?
Indeed. That as my thought as well. The video-decryption pointed out @6:45 is contradicted @7:55 where it is pointed out that only two packets are useless if one is corrupted during transmission.
The encryption cannot be parallel, the decryption can be parallel though.
@@vamPierchen0 I realized that as well. I think it was just either a wrong word or encryption sounded like decryption.
Because if the recipient wants to jump ahead to the middle of the file, the sender still needs to generate the cyphertext all the way to that point
Yep, it can be parallel decryption
@@Tony-cg5it you can do the parallel decryption as described in the video, but only if the sender does the entire encryption and transmits it without error
Fantastic explanations, thank you!
6:44 Wait, I think CBC _decryption_ is both parallelizeable and random-access. Just decrypt the current block, and XOR it with the previous one.
Mk Km how is it parallelizeable if you need the result of the previous one to decrypt the current one?
@@ninjafish1504 You need the previous _ciphertext_ block. Unless you use another layer of encryption, these blocks are what is sent over the wire and what you have in the receive buffers. And in that case finding a previous block is just a matter of decrementing a pointer.
But isn't the bottleneck with the encryption? Since you have to wait for all the previous blocks to be encrypted and sent, right?
For the counter mode once you have your keys this is running exactly like one-pad. The key size is the same as the entire message steam. But you are generating key material on the go.
Great video! Esecially considering that it's relevant for my next exam. Also, I'd like to request a playlist for these cryptology videos as I can't seem to find an existing one.
As always - brilliant explanation ;)
Great explanation! Thank you
Amazing video! i understand absolutely nothing but your videos have been helping me to sleep since when i get confused, my brain is disoriented and everything seems impossible to do so i am able to do nothing but sleep.
Perfect explanation
I analyzed software serial numbers "protected" by AES-256 ECB. I think it took less than 15 Minutes to find the original 128-bit key. This was on a PowerPC 750 processor (Mac OS X 10.2), IIRC. Fun times. 😉
So engaging - Thank you!
Note that rolling your own code to do this is almost always a bad idea. With Galois/Counter mode the additional complexity of operating in a finite field (GF(2^128) is usually used, with a 128th-degree irreducible polynomial over that field) means that the scope for errors to creep into your code is much bigger. You're much better-off using an open source library (these can be written to make use of some new hardware CPU instruction codes specifically intended to do multiplications over finite fields).
One important detail that I missed in the video is that for CBC mode you need to include the IV (initialization vector) in the ciphertext.
The same goes for the nonce in CTR/GCM mode; it has to be transmitted to the receiver so they can actually encrypt the message. You can just send it as plaintext, though.
5:35 - *_"[The IV] is_** not **_a secret. That just gets put on the message"_* 🙂
@@JivanPal Ah alright, thanks for pointing this out. Still it's important to note the same for the nonce, which may not be 100% obvious.
@@mgerber59, yeah, I totally agree that it could've been clarified and discussed further.
Not all CBC variants include the IV in the ciphertext, if there are other protocol mechanisms. For example you can have an implicit IV derived using secrets from the protocol handshake, e.g. IV=KDF(key: master secret, label: “IV”, context: packet counter) or such.
I am studying for the SSCP exam I am taking in a week from now. I took Security+ and passed, but I am always confused by the block cipher modes. This video helps alot because you really explained it well while putting it into examples on paper for me. Still....while being fascinated by encryption and all the nuances of it, I am just not able to really get it because I haven't worked a day in the field. What would you say I should do to help me expand my knowledge of encryption in a way that I can actually get in real world experience? I want to eventually get a job in cybersecurity and have working knowledge and skills of doing this stuff on my own. I am in college and trying to get off of disability to return to working status. Cybersecurity is the field I have chosen to get in to when I hopefully get back to being able to work again. I am at a huge disadvantage because I haven't been able to work in the IT field for years, so I need to get practice in at home. Thanks in advance.
Well how'd you fare in the exam mate? And how'd the job hunt pan out? I hope it's been fine
Amazing video!
Great video!
As far as i understood, the decryption is parallelizable in CBC, as well as random read access. 6:45 Correct me if im wrong
Can you do a video on how key schedulers work?
speaking of modes of operation
MMC has two operating modes: author mode and user mode. In author mode, you can create and modify a console's design by adding or removing snap-ins and setting console options. In user mode, the console design is frozen, and you cannot change it.
i have a question about the counter mode encryption.
if the nonce+counter is not private, only single use, that means it is theoretically known to the attacker. if we also assume that the method of encryption is known to the attacker because security through obscurity is foolish, then what prevents the attacker from encrypting the nonce+counter themselves and xor'ing this key with the cyphertext to crack the message? surely the encryption system must be asymmetrical (ie rsa) to ensure that only those with a private key can encrypt. am i correct?
So in counter mode, if i don't even need a decryption method, couldn't I just use a a hash function to create the block key from the counter and key? What's the problem with that idea?
the function used needs something secret to be secure, the nonce is public, the counter is easily calculated. an encryption function takes a secret key, a hash function does not.
using a hash function would be trivially easy for anyone to decrypt.
@@dataminetk Yeah that is why the counter should be combined with secret key before hashing. Only with the correct key should you be able to recover the stream key for any given block.
@@sunday87 that'd be turning the hash into a HMAC, which would be secure (I think - haven't thought on that in depth).
How do you transfer the key or iv or whatever securely when they can't yet open the encryption?
I have the exact same arm-armpit tic as Dr. Pound, and each time I watch one of his videos I have to do my best not to inadvertently imitate him 🤣
Watching this videos the question does not leave me alone: is it usual practice of all computer science faculties to use line printers paper for explaining ideas. When I was a student here in Moscow our professor who taught programming course did just the same. And I've been wonder if there is lack of usual A4 paper in our University or there is excess of line printer paper here.
I love this man
6:43 Isn't CBC decryption of a block possible with just ciphertext from the previous block (and encryption key ofc)? In that's the case, why can you jump to the middle of that movie without decrypting everything in between?
The thing is AES CTR is AES ECB but used in a different way like you encrypt NONCE (32bits) + IV (64bits) + COUNTER (32bits) and you then XOR each block of 128bits and then increment COUNTER after each block.
So ECB is CTR but used a different way.
But yeah I agree that there is no way to detect any bits being changed, unless you use something like HMAC-SHA etc, but that increases your data size.
quite helpful!
I am confused why the CBC mode can't be parallelized during decryption?
So in counter mode. Is there even a reason to use AES? We are not decrypting at all, can't we just do something with the nounce and key and put it to SHA256? I'm assuming SHA256 is faster and even harder to recover the key
Mike looks so serious on this thumbnail
Cipher block chaining has the weakness that you can manipulate individual bits in a controlled manner. So you switch to counter mode, which has this weakness on steroids. It seems more effective to use Electronic Codebook, but make a trivial modification to input blocks to make repeats less likely. Instead of encrypting the counter, XOR the plaintext with the counter before encrypting.
Flipping bits of the ciphertext in counter mode affects decrypting *only those bits.* Whereas flipping bits in ECB or CBC mode affects decryption of the entire block or that *and* the next block.
Then you have another problem: on EBC with a plaintext-XORed counter, if you get the same cyphertext twice, you know they are equal by an offset, which is the distance between the blocks. So the ideal is to use the counter twice: one for XORing your plaintext data, and other which gets encrypted and XORed with the cyphertext, which solves those problems quite nicely.
There is another problem with counter mode based operations and that's the maximum message size. The counter will flip at some point
How many messages are 2^128 bits long... Total computer storage of the world is expected to be 175 zettabytes by 2025, which works out to about 2^80 bits if I did my math correctly. (log(10^21 * 175 * 8) / log(2))
@@RedwoodRhiadra why should the counter be 2^128? More often 32 or 64 bits and the problem with 32 bits is self explanatory
I suppose he was refering to the fact that they are non-reusable, so after sending many messages, the counter will be the same as for the first one. I don't see that as a real problem either though.
@@yorickdewid If you are using a too short counter, that's an implementation problem, not a problem with the mode. The mode itself allows 2^128 different input values (for each key) before you get conflicts, so you can encrypt up to 2^128 blocks with the same key - either in one really large message, or as multiple smaller messages. (And with CBC, you should only use it for ~2^64 blocks, before you get a high probability of repeated ciphertext blocks).
@@yorickdewid Assuming a 128-bit block, you need the input to be 128 bits if you don't want to pad it.
Helloooo anyone gonna mention that we just got delivered the first 4K Computerphile video ? today can't be a bad day not matter what.
Aside from the current remote videos Computerphile has been 4k since Jan 2017 :) HTH >Sean
@@Computerphile That's odd, the max quality for me on those videos is 1080p, maybe part of the pandemic related measures from CZcams to limit data flow. Thank you for the awesome content as always!
Is the initial vector similar to a salt that you'd use with a hash before you put it through a hashing algorithm?
Adam Mercer It’s a very similar idea, yeah. Neither need be secret, though the attacks they’re defending against are slightly different
Why not XOR the counter before encryption? It would no longer be vulnerable to bit flip attacks, and would have all the positives, am I wrong?
Then you would get a problem almost as bad as with ECB: Say you have two plaintext blocks that differ in just one bit, and their respective counters also differ in that same bit. Then the XOR cancels the bits out, two copies of the same block get encrypted, and you get two ciphertext blocks that are exactly the same.
Where is the camera that it looking over his shoulder? I feel like i should be able to see it :)
I seem to remember I used a sucker and stuck it at the top of Mike's whiteboard :) >Sean
@@Computerphile ha ha, i was thinking that hanging it from the roof seemed a bit much! I didn't think of a suction cup!
Using counting mode doesn't require implementing decryption at the cipher level. It made me think that using this techinique we can implement a symetric encryption algorithm using a secure hash function such as SHA256 or SHA512 and using the counter initializer as the key.
It would work like this:
- Apply a random salt to the user supplied password and take the hash of the result (save the salt);
- Use this hash as the counter's initial value and increment it for each block;
- Take the hash of the counter for each block;
- XOR the input message with the resulted hash of each block.
My question is: Is this secure?
Where would you store the salt? At the beginning of the cipher text?
I don't know about secure, but it's not nearly as bad as the other suggestions in the comments about using a hash algorithm. The IV/nonce/counter is supposed to be public. A better scheme would be to use an hmac (keyed hash function) as your irreversible function, and put the IV as is at the beginning of your cipher text (where it belongs).
But where does mike get those jumpers from?
Would be awesome to know what how random in a computer actually works. Can it be broken?
Depends on the algorithm. In most cases, short answer is yes. But there's tons of factors.
What about just prepending each message with a simple salt header of unknown size? e.g. message is length 120-127 bytes in length, gets pre-pended with a header that's first byte is a 4 bit header length value, 4 bit random, and then 1-7 bytes of random data. That means all encrypted messages are dissimilar, and can be decrypted independently.
@@henrikoldcorn You are confusing 7 bytes with 7 bits.
fantastic
I found a method for remembering less passwords : if you can remember n strings, you can create n - 1 + n - 2 + ... + 1 passwords by combining a diferent pair of strings for each passwords. for exemple if you can remember 4 strings, you have 6 passwords :
s0 = cat
s1 = dog
s2 = tortoise
s3 = fly
p0 = catdog
p1 = cattortoise
p2 = catfly
p3 = dogtortoise
p4 = dogfly
p5 = tortoisefly
(dont use those strings but you get the idea) and if you have 5 strings, you have 10 passwords, 6 = 15, 7 = 21, 8 = 28, 9 = 37... Each password either countains half of the infomation of half of the other passwords or no information. It is also possible to use a combination of more than tow strings to create more passwords with the same amount of strings.
What do you thin about that ?
Could you explain zero cleare malware and how it works?
11:45 But doesn't CBC and ECB also need message authentication? And obviously CTR needs to produces a lot more authentication tags than CBC.
12:32 so with counter mode you don't even need to stick to reversible encryption and could use irreversible methods e.g. hashing as well?
Yes but... you need to use keyed hashing otherwise it's trivial to decrypt since the input to the encrypted blocks IS the IV/counter/nonce. Lookup "hmac" it's a method for hashing with a key.
I literally just received a mail saying computerphile just uploaded a video with title "Modes of Operation", I definitely knew it is by Dr. Mike Pound and here I am.
I still don't understand the last part, if the nonce is not secret can't it be used by an attacker since the encryption algorithm is also known?
Everybody knows the encryption algorithm, but not everybody knows the specific key used to encrypt a particular message. That is, everybody knows _E_ in terms of some generic key _k,_ but the specific _k_ we use should be a secret, so that not everybody knows the specific _Ek_ that is used to encrypt our message.
If the encryption function itself is secure (e.g. because the key space is sufficiently large and cannot be brute-forced), then decrypting the ciphertext into _M_ ⊕ _IV_ is not feasible unless the key is known. As such, it does not matter if _IV_ is publicly known, since it is only useful if decryption can be successfully performed.
Please tell us about XTS mode.
This is a really great video. Can I suggest that someone puts a request in to change the moniker ‘nonce’....... how has no one noticed this before?!
They have. Problem is it’s uk slang and us jargon.
Kevin Melling I really didn’t want to be ‘that’ guy. But this is too weird to ignore as a Brit! And the video is British, after all.
here in the US, where almost all things cultural are hijacked, the word has no pejorative value. it's just a word.
For a very long time Carbon Nanotube science was all about detecting and enriching for CNTs.
To be honest, it's digital perl-clutching isn't it. nonce derives from "N" (any number) + "once".
At 06:44 (the example with a movie encrypted with CBC) it is stated that one cannot easily jump through the movie, because one needs to decrypt all predecessing blocks. This is incorrect. With CBC, encryption indeed cannot be parallelized, however, decryption can be parallelized very easily. One always needs only two succeeding blocks of ciphertext to get the plaintext of the second block (just decrypt the second block and xor it with the still encrypted first one).
Link to the Feistel Cipher video czcams.com/video/FGhj3CGxl8I/video.html
Thanks - now added to description too >Sean
13:47 With an IV of 96 bits, you can encrypt at least 2^96 blocks of information before you need to change your key (More if your messages are longer), which is much more than any data center can contain. The limit that the IV puts of the amount of messages you can encrypt with one key is thus purely theoretical, and other limits are reached much quicker, like the recommendation to only encrypt 4 GiB with one key.
It could still be an issue if you use your IV space sparsely. Like if you have multiple streams in the same session and don't give enough bits to the separation between streams, or somehow run through separate streams fast enough to use up the bits allocated to that.
You're forgetting about the birthday paradox
@@softwarelivre2389 If you simply increment the IV by 1 every time you use it, the birthday paradox is not applicable. With a random IV, you should indeed change it way more often.
@@tomvleeuwen yes, but then you can use the IV to count the amount of requests/encryptions, which is a data leak by itself
@@softwarelivre2389 In some cases it can be, but in many cases the attacker already knows that, for example if you want to have a packet counter for replay protection that you want to check before decryption.
Incremental IVs are very common in VPNs for example (both OpenVPN and ESP use incremental IVs for GCM). I was triggered by the words "hard limit" in the video, implying that they are all used.
What if you just append random salt to every block and discard it after decryption?
Why do we even need something like AES for counter mode? Couldn't we just have the nonce be the key and use some hash function for the "encryption"?
Block ciphers are amongst the fastest cryptograpic operations, it just substitution and shifts. It's not uncommon to build a cryptograpic hash function from a block cipher
explained at the end of the video... you need to have the key shared but secret... nonce is not secret, and has a pattern to it... incremented for each block... encryption removes that pattern.
@@MikelNaUsaCom Garbaz is actually right, use the key instead of the nonce, and keep it secret obviously, then you can use a hash function instead of a block cipher in counter mode. Salsa20 and ChaCha20 are two stream ciphers that kind of work like that.
You’d need a hash that is fast and is appropriate to be used as a keyed hash. It need to to behave as a perfect pseudo random function to someone without knowledge of the key. Hash based key derivation schemes does something similar; generates an arbitrary long array of perfectly random bits using hash operations. You should stick to some preexisting approved scheme though, as many hashes (md5, sha1, sha2) have weird behaviors you don’t want to to get into (for example, length extension attacks where attacker can add data to hash without knowing the original plaintext)
My question is how does the receiver know what the nonce is... They will need to know in order to xor it with the block.
Nonce is always send in the clear with the message
In counter mode why is the xor done after encrypting the counter and not before?
@@Gorzoid That makes sense somehow I assumed the number would be used to generate pseudo random numbers but rewatching the video I must have made that up in my head.
There are modes that do both, xor before and after the block operation
When the IV isn't a secret anyway, why exactly does it have to be random?
Just dont really understand how the nonce is echanged/syncronized between the parts.
The nonce is public. Just gets sent as is.
9:04 Hoo-ray!
Not gonna lie, I was hoping from the title this was gonna be about the work of Larry Tesler.
(I missed the previous video so the context was unknown to me.)
ECB, CBC, CTR, GCM
Next level: CBT
Mike Pound is cipher-daddy
I'm waiting for the GCM video
For a split second I seem to grasp something... but then its gone
Watch the video again and write it in code.
How can I use public-key cryptography to verify my identity if I happen to lose one of my online accounts (say twitter)?
I comment here to get notified when some1 helpful answers here ...
I think that there are some social recovery things going live on the Ethereum blockchain, they're early tho and idk much about them
Very similar to SSH, you could always exchange a key with the provider in advance that establishes your identity but is not your login and password (basically a recovery method based on PKI). However the question is then, why don't you use the PKI to simply establish your identity all the time.
You could make the same question about PKI in general, how do I re-establish my identity if I lose my private key. The answer is, you don't unless you have a method of regenerating your key (eg. a master key such as in LastPass).
Short answer: Use a password/key manager like LastPass or KeePass to keep track of at least one of your regenerative identities.
So GCM once again breaks the seek-ability of CRT :v
Because you need the entire message to authenticate, not just arbitrary blocks from the middle?
Good god he is a god
Nonce vs block counter could have been a little bit better explained. You mention it very briefly but then example isn’t great. As nonce typically is e.g. 1,2,3,4... the block encrypted must not be nonce, nonce+1, nonce+2 etc because you’d have counter-reuse immediately, breaking counter mode. But eh, it gets a bit dirtier writing e.g. (nonce, 001), (nonce, 002) etc I suppose.
Has anybody ever figured out exactly what paper is used on Computerphile?
Its Continuous stationery green-bar (on white), landscape fan-fold printer paper.
Reckless Roges thank you!
Someone knight this man
I think Dr Pound is currently MBE material. (Give him something to aim for.)
Block 45 Rotation?
More image processing stuff, like sharpening or such
Since we don't need to decrypt, would it be safe if I was to use an hash function instead of an encryption function in conjunction with counter mode? The key would be a string to be concatenated to the nounce and then fed to the hash function
Mike "The only professor who chose C#" Pound
Interesting, for me too, he is the only one I remember from that video
Slowing the speed to .75 is extremely helpful
Be careful is nonce1 = nonce2 + x where x less than the number of total blocks
i got questions ,lets assume i've completed python course and made few projects. but others skills do u need in a working environment and what are the best resources to learn those because i never apply for job m afraid if i got job but not ready for it the fear come i learned English at the age 19 after whole new world opened up but m i think m really late to the game
qwerty king if you want to develop the skills related to programming in the workplace, I’d suggest participating in Hackathons and contribute to open-source projects.
Not Mike ~0.45 kg?
No! He's Mike $1.217USD.
Didn't know that Frodo Baggins was such an expert in cryptography...
right