Cryptography Basics Flashcards

Question

A hash example

Answer 1

``` • SHA256 hash — 256 bits / 64 hexadecimal characters • My name is Professor Messer. -SHA256 hash: 19da9a2e26f3bff67f0522f962851c42542b8659333ac53397c8d65aa7a3f871 • My name is Professor Messer! -SHA256 hash: 54381cae1eea10892d81c8688d06d1928b4ee8495061a792864f83092b033aea ``` 19da9a2e26f3bff67f0522f962851c42542b8659333ac53397c8d65aa7a3f871 54381cae1eea10892d81c8688d06d1928b4ee8495061a792864f83092b033aea

Answer 2

``` • Hash functions —Take an input of any size —Create a fixed size string —Message digest, checksum •The hash should be unique —Different inputs should never create the same hash —If they do, it's a collision • MD5 has a collision problem —Found in 1996 —Don't use MD5 MD5 hash: 79054025255fb1a26e4bc422aef54eb4 ```

Answer 3

• Verify a downloaded file —Hashes may be provided on the download site —Compare the downloaded file hash with the posted hash value E47df00b078b5f9daed0871f0e90d33faf906ba5d5f13b4b02b98351a819e3a7.iso 63177ed9a01f2116671655bf06266e5d *ubuntu-17.10-beta2-server-i386.iso • Password storage —Instead of storing the pa sword, store a salted hash —Compare hashes during t e authentication process —Nobody ever knows your actual password

Answer 4

``` • Prove the message was not changed — Integrity • Prove the source of the message — Authentication • Make sure the signature isn't fake — Non-repudiation • Sign with the private key —The message doesn't need to be encrypted — Nobody else can sign this (obviously) • Verify with the public key —Any change in the message will invalidate the signature ```

Answer 5

• Arbitrary number —Used once —"For the nonce" - For the time being •A random or pseudo-random number —Something that can't be reasonably guessed —Can also be a counter • Use a nonce during the login process —Server gives you a nonce —Calculate your password hash using the nonce —Each password hash sent to the host will be different, so a replay won't work

Answer 6

•A type of nonce —Used for randomizing an encryption scheme —The more random the better • Used in encryption ciphers, WEP, and older SSL implementations

Answer 7

``` • A nonce most commonly associated with password randomization —Make the password hash unpredictable • Password storage should always be salted —Each user gets a different salt • If the password database is breached, you can't correlate any passwords —Even users with the same password have different hashes stored ```

Answer 8

• Strong cryptography vs. weak cryptography —It's all relative • Practically everything can be brute forced —Try every possible key • Strong algorithms have been around for a while —That's part of the reason that they are strong —Wired Equivalent Privacy (WEP) had design flaws • Strong algorithms —PGP (Pretty Good Privacy), AES (Advanced Encryption Standard) • Weak algorithms — WEP (design flaw), DES (Data Encryption Standard - 56-bit keys)

Answer 9

•A weak key is a weak key —By itself, it's not very secure • Make a weak key stronger by performing multiple processes —Hash a password. Hash the hash of the password. And continue... — Key stretching, key strengthening • Brute force attacks would require reversing each of those hashes —The attacker has to spend much more time, even though the key is small

Answer 10

•There's very little that isn't known about the cryptographic process —The algorithm is usually a known entity —The only thing you don't know is the key •The key determines the output —Encrypted data —Hash value —Digital signature • Keep your key private! —It's the only thing protecting your data

Answer 11

• Larger keys tend to be more secure — Prevent brute-force attacks —Attackers can try every possible key combination • Symmetric encryption — 128-bit or larger symmetric keys are common —These numbers get larger as time goes on • Asymmetric encryption —Complex calculations of prime numbers — Larger keys than symmetric encryption —Common to see key lengths of 3,072 bits or larger

Answer 12

•A logistical challenge —How do you transfer an encryption key across an insecure medium without having an encryption key? • Out-of-band key exchange —Don't send the symmetric key over the 'net —Telephone, courier, in-person, etc. • In-band key exchange —It's on the network —Protect the key with additional encryption —Use asymmetric encryption to deliver a symmetric key

Answer 13

•There's a need for fast security —Without compromising the security part • Share a symmetric session key using asymmetric encryption —Client encrypts a random (symmetric) key with a server's public key —The server decrypts this shared key and uses it to encrypt data —This is the session key • Implement session keys carefully —Need to be changed often (ephemeral keys) —Need to be unpredictable

Answer 14

``` • Low power devices —Mobile devices, portable systems —Smaller symmetric key sizes — Use elliptic curve cryptography (ECC) for asymmetric encryption • Low latency — Fast computation time —Symmetric encryption, smaller key sizes • High resiliency — Larger key sizes —Encryption algorithm quality —Hashing provides data integrity ```

Answer 15

• Confidentiality —Secrecy and privacy —Encryption (file-level, drive-level, email) • Integrity —Prevent modification of data —Validate the contents with hashes —File downloads, password storage • Obfuscation —Modern malware —Encrypted data hides the active malware code —Decryption occurs during execution • Authentication —Password hashing —Protect the original password —Add salts to randomize the stored password hash • Non-Repudiation —Confirm the authenticity of data —Digital signature provides both integrity and non-repudiation • Resource vs. security constraints —An ongoing battle — Browser support vs. supported encryption —VPN software support vs. supported algorithms