/cyber/ - Cyberpunk & Science Fiction

>>25676

if you both exchange all parameters publicly then how is it impossible for me to do

Y ^ a mod p = K

or

X ^ b mod p = K

and thus decrypt their shit?

>>25681

Because in equation:

Y ^ a mod p = K

they don't transmit a or b. Its their secret values, (private keys) that never leaves their computers. Only X, Y, g and are known publicly.

>>25682

my bad, I misread your text

I'm not gonna pretend that I fully grasp what's going on here but I think it's really intruiging in how both K are equal to eachother.

will look into this, nice post.

Here is the script: http://fpaste.org/233565/63721314/ read it carefully. I've tried to do it as simple as I could, with comments. There are usage examples commented out in script. Uncomment one by one and see what is happening.

When doing key exchange, one secret key and one public key yield only one K value, which is sometimes not what you want. You want encrypt each message with new keys to make analysis harder. This can be done by generating new private/public key for yourself, but using already known public key of receiver (Bobs public key). This will yield new K for that message, and called Ephemeral-Static DH. If you always discard those newly generated secret keys, you will get Perfect Forward Secrecy: https://en.wikipedia.org/wiki/Forward_secrecy

Diffie-Hellman Key Exchange lacks one important feature - authentication. You always want to make sure that person who is encrypting message really is someone he claims to be. If you ever use OTR, it will suggest to authenticate through some question, answer for which is known only by you two. DO NOT SKIP IT IF YOU WANT SECURITY, as authentication is more important from crypto POV than encryption or ciphers themselves.

In other protocols, there is another algorithm involved just for that. If you look at TLS cipher suits, you will see, beside DH, some signing algorithms - RSA, DSA, ECDSA. They make sure that all message originated from the same node. Some keys are signed by Central Authority to involve centralized trust in this system.

>>25683

It is rather hard to grasp at the beginning, but when you understand it, this all becomes straightforward and clear.

>>25705

>and that made my tiny little brain hurt for a while.

I'm sorry, shouldn't have done that. I just wanted to show that these are different values, and capital A and small be could be misinterpreted.

>The only thing that worries me about encryption is man-in-the-middle attacking.

>if a man in the middle can copy g, p, A, and can copy B, I worry that somehow he will be able to deduce a or b and thus deduce K.

Large modulo will make sure that does not happen. By "large" I mean really large - 260-300 decimal numbers (doesn't even fit in my screen).

Man in the Middle in general still is unsolved problem in cryptography.

http://www.newamerica.org/oti/doomed-to-repeat-history-lessons-from-the-crypto-wars-of-the-1990s/

>>25675

Interesting, recently had to get a hardware encryption module (SHA256) working on a microcontroller it was way faster then letting the microcontroller doing it via software.

AMD's new carrizo chips come with hardware that can be used for encryption also "A cryptographic co-processor is also included, and it's used to handle RSA up to 16,384-bits, sha-1 through sha-512 and a host of other cryptographic methods."

>>25706

Wont let me un-comment the code, but I think I get the idea (I'm not the other guy btw).

Great post, I'm fascinated by Cryptography and want to understand it better, conceptually, so that when I write code I am able to understand risks and pitfalls much easier.

There is one thing I am especially interested in right now: Entropy for generating (pseudo)random numbers. In short, what the most common and effective ways to generate the random hex for our keys if we need them?

For the benefit of others: Why is this a big deal? What is the risk in generating keys with very low entropy?

>>25706

You could have used the wikipedia entry picture to illustrate the concept better user, maybe less aneurisms would have happened.

Anyways good thread m8 i recently went heads on cryptography and learned Vinegere first and wrote some stuff in python and JS.

>>25778

less combinations are required to crack them i suppose, the longer it takes for a third party to break the code, the better, remember cryptography is not about encryption and decryption algorithms is about obfuscating/hiding information, the important things are the concepts behind communication dynamics (i.e:how to agree on a key without drawing attention to you or your partner, how to safely start a secure anonymous communication channel, etc), the algorithms are just the tools and knowing how to employ them and their limitations is what makes a good cryptographer.

>>25749

Even some software is fast enough. Hardware must be amazingly fast. Have any speed test results left?

>>25706

You are supposed to save it to a file on your computer (say, named dh.py), uncomment section and run it in terminal with command "python dh.py".

>>25778

>In short, what the most common and effective ways to generate the random hex for our keys if we need them?

In Python script above, there is a function that gets secure, high quality entropy from operating system. Its effective and common. On *unix, special devices for entropy are called /dev/random and /dev/urandom. There is small difference between these two, but just ignore for now. These devices collect entropy from multiple sources: disk read/write operation, keystrokes, network traffic and so on. Data is mixed, hashed and stored. Here is some code: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c

On linux, you can play with this command:

cat /dev/urandom | tr -dc 'a-f0-9' | fold -w 128 | head -n 1

Length - 128 characters

In software, sometimes strong cipher are used random number generators. Encrypting zeros with user-provided seed as a key (mouse twitching, slamming keyboard) will result in high quality entropy. Cipher output is by definition should be random.

There is another generator called Blum Blum Shub: http://pages.cs.miami.edu/~burt/learning/Csc609.062/docs/bbs.pdf but it needs a seed and two prime numbers generated each time.

>What is the risk in generating keys with very low entropy?

Such keys will be weak and it will be significantly easier to just attack them with brute-force. This happened in real life in 1996 (or '97) with Netscape SSL. Due to a bug in random number generator, keys had less than 80 bits of entropy. Two students cracked keys with shitty PCs in a few days and sent bug report.

You can count the number of possible keys - 2 ^ 80 in bugged case and 2 ^ 1024 in normal case. There is a difference.

>>25785

Picture is from wikipedia.

>i recently went heads on cryptography and learned Vinegere first and wrote some stuff in python and JS.

Post your Vigenere script as illustration.

>>25790

>>25778

fyi /dev/random is more secure than /dev/urandom

/dev/urandom is probably secure enough but there is a lot of serious shilling going on so if the difference is negligible why does the NSA invest resources into convincing people to use the latter?

and also: configure iptables to block icmp timestamp packets, if attackers know your system time it reduces the value of your keys' entropy.

>>25676

I'm confused as fuck.

>>25840

This is actually a case of where Wikipedia explains it better than the poster.

Two parties choose a private colour of paint each and then decide on a public colour.

They mix their private colour with the public colour and send this new colour of paint to the other party.

Each of them takes this new paint from the other guy and mixes it with their private paint so they have both used the same 3 paints and end up with the same final colour which is now their private encryption key.

Replace paint with really big primes.

I prefer old timey cryptography

>>25893

you mean completely insecure cryptography?

>>25897

"rot13 is weak so i always use it twice"

>>25897

maybe he means one-time pads, those are about as secure as it gets if you can keep the book safe.

>>25913

everything you just said was so heavily encrypted I couldn't make it out

>>25918

i meant i run multiple rounds of the good old rot13 encryption cipher for additional security. tinfoil masterrace.

>>25675

Hahahaha. Exactly. Aesthetics.

>>25943

Nothing more, nothing less.

>>25918

>one-time pads are secure

they may be perfectly secure, however there's also the problem that you have no way of knowing that the decrypted ciphertext is the same as the plaintext.

>>25706

Useful links:

https://tools.ietf.org/html/rfc2631 Shows how to generate g on demand (in case you don't want to use pre-computed) and also how to validate public keys

https://www.youtube.com/watch?v=YEBfamv-_do Easy intro in DHKE

>>26018

If this poses a problem, there's nothing stopping you from adding a checksum at the end of the message

>>25796

>>25790

>negligible differences between random and urandom

>secure enough..

>when talking about encryption

If you don't know shit don't pretend you do you fucking idiots. This kind of arrogance is the source of half of the misinformation in here. There is only one difference between these two and that is what happens when the kernels entropy pool runs out.

/dev/random will block until entropy becomes available, usually by user actions

/dev/urandom will generate pseudorandom numbers usually with hash functions, these are very predictable and should under no circumstance be used in encryption.

The random number component of encryption isn't a trivial thing. There's a reason NSA spent brouzouf on pushing weak random number generators on common encryption software.

>>26025

alright then go distribute a random key for every message. Unless you physically do the handoff you're relying on a crytography scheme which is not perfectly secure to do the key handoff.

>>26025

Distributing key material is the main problem. For checking plaintext you can add checksum inside or/and outside of message.

One-time pads are still used in the military to send short command codes via radio. Handoff and schedule are distributed manually though

>>28323

FYI you should actually use urandom for crypto.

http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/

>>25676

I finally understand this one. Basically, it hinges on the relationship

(x mod y)^z mod y === x^z mod y

Once you've got that, you can simplify the two expressions.

Alice's:

Y^a mod p

(g^b mod p)^a mod p

(g^b)^a mod p

g^(ba) mod p

Bob's:

X^b mod p

(g^a mod p)^b mod p

(g^a)^b mod p

g^(ab) mod p

Voila, same thing.

>>28323

>If you don't know shit don't pretend you do you fucking idiots.

Easy there, chill out. I know the difference between blocking and non-blocking CSPRNG, even posted link on source code for the driver, which describes it in-depth.

The difference between those devices is small, and indeed negligible for someone doesn't even know wtf DHKE is yet. And its totally negligible for someone who barely use random pool at all and runs this script above once or twice, because

>when the kernels entropy pool runs out.

never happens, because its fucking big.

Instead of being all edgy, you could have said: "NOTE that /dev/urandom re-keys itself when pool runs out, thus becoming more predictable and weaker with extensive use. Use /dev/random for better-safe".

Control your synapses or something.

>>28462

Oh there's a blog post saying that entropy is irrelevant for random numbers in cryptography. Does it have any sources? No? Well this seems legit. Cryptographers were wrong all along.

Hey,

I started using gpg a while ago and there remains one element I don't understand at all.

What are expiration dates and revocation certificates really doing ? I get what they're used for and why they're needed, but how does it work ?

Has to do with key servers, right ?

>>28763

basically gpg expiration dates allow for one key to be assigned to one person for one period. In the future, if someone asks "hey I want a new gpg" and y gets the same as X, then X and y are both compromised. To avoid this:expiration dates allow y to use X's gpg after a period, and only after it expires. At least this is my understanding of gpg expiration dates. Then again itd have to be an astonishing coincidence y and X get tge same gpg keys.

>>28768

That is not how I see it, but again, I'm pretty new with crypto and gpg.

The way I see it is that expiration date serve the same purpose as revocation certificates, that is : allowing the owner of the key to change from a key to a new one (though in this case it's more to do with increasing the key's security than dealing with a compromised one).

Beyond that, the thing I don't understand is how it's implemented, not what it's for.

>basically gpg expiration dates allow for one key to be assigned to one person for one period.

Okay, but this can only work when dealing with key servers, right ? I don't see a way for gpg to know and share this information on its own

>>28771

>that is : allowing the owner of the key to change from a key to a new one – and helping mitigating problems caused by lost keys.

Read myself back and thought I should rephrase that

>>28772

Im pretty new myself so take my post with a grain of salt.

>>28771

gpg adds meta information to the keys, the key includes the expiration date along with your name, email, etc.

>>28785

I initially thought you didn't understand my question but I think I get what you mean.

So when people get my public key, they obtain this information as well and know if its outdated ?

So it means the key is not "cancelled", right ? It's just marked as outdated, but still usable ?

>>28763

>What expiration dates and revocation certificates really doing ?

Expiration shows how long key will be legit. After that date, user is supposed to create new fresh key and sign it with old one. If user continues to use expired key, then something suspicious is going on (someone found it, that is). So basically its a mechanism to say: "I'll use this key for such period, after which I cannot vouch for its security (and hopefully I'll make a new one)". Rationale is that some people use weaker keys but rotate them faster, and they don't want a situation where there are 2-3-5-10 legit keys floating around and no way of telling which one is current.

>What revocation certificates really doing ?

Alarm system integrated with keyserver. Allows user to warn others that key was compromised. If you don't use keyserver often don't even bother with it. It is rarely used.

seeing as this is cryptography general does anyone have any good resources relating to more classical cryptography, things prior to WWII?

>>30671

"The Codebreakers", by David Kahn would be something you are looking for. By the way, NSA attempted to halt its publication because of some parts of the book concerned the agency. It was published, but some parts concerning inner workings of the agency were removed.

>>30676

Looks to be just what I was searching for, thanks anon.

One of the things that bothers me is the way TLS/SSL is used with PKI (public key infrastructure). It implicitly drops a man in the middle (Cert Authorities) into every connection.

Not only do you have to trust the CA that signed the cert, you're trusting hundreds of CAs in your browser's root cert list. If any one of them is compromised, then every website on the whole Internet is vulnerable to MITM. Few if anyone ever checks the CA – AND there's no way for me to know that MyBank.com didn't switch CA's. A CA can generate a cert for any domain even if the domain owner didn't want them to. Diginotar CA was breeched and forged certs for google.com, even though that wasn't the CA Google uses, your browser would show a big happy green "secure" bar/logo when browsing via the compromised cert.

Then there's verisign, which used to be the only CA, and which is known to be on the take from the NSA. So, there was never any security in SSL in the first place, and there still isn't.

What could be nice is if we could use plain old symmetric stream ciphers for TLS/SSL.

If only there were some protocol to ask the user for a username / password, and then key the stream ciphers with that… OH WAIT, HTTP Auth exists.

DH key exchange is only useful to exchange a shared secret. Once we've established a shared secret (and of course that's exactly what we do via account/passwords) then we can just use the password to key the stream cipher on both ends, and start encrypting without needing DH key exchange (after account creation) and since the window is so small we don't need to trust a corrupt CA system either. A MITM would have to be persistently MITM-ing every connection or your password would stop working.

HTTP Auth (digest) goes something like this:

User sends request to connect + user name.

Server sends a nonce (random string).

User HMACs (hashes) the nonce with their passphrase.

User sends resulting hash to server as a proof of knowledge.

Server HMACs the nonce with the passphrase and compares this to the one the user sent.

If they match then the server knows that the user knows the password.

Now, what they could do instead is exchange nonce values (possibly signed via each the other's private keys). HMAC those nonces with the password (the shared secret).

Then just take the resulting HMAC value and key a stream cipher with it.

A user's browser would check to see if the user has established a connection with the server and pop up the HTTP Auth user/pass dialog. User enters that and THEN the connection is made (no phishable login page cluttering up our sites). Similarly, account creation would occur via dialog outside the web page (which is the only time PKI need be used).

The browser could cache the user/pass if desired, just like they already can.

A MITM would see the nonces be exchanged and then immediatly the connection is encrypted. They can't modify the nonces or the encrypted tunnel will fail. A CA or MITM doesn't know the password so they can't spoof either end.

Of course, "privacy" nutjobs will balk at sending one's user ID in the clear – not realizing every packet has your return IP address, which reveals your location and the ISP sells such data regularly to marketing firms anyway. There's Tor, but only shazbots think it's fucked too:

http://thestack.com/chakravarty-tor-traffic-analysis-141114

Why the fuck don't we have the option to key HTTPS via HTTP Auth? Because that would be ACTUALLY SECURE. Think about it: You could go to your bank in person, setup a password without DH bullshit or CA MITM, and just use plain old pre-shared key (or share a passkey with your friend in person), and have maximum security for important stuff without a stupid as fuck China/Russia/USA spy-agency-friendly CA MITM everywhere. You could opt out of the CA system AND STILL BE SECURE. That we don't have this simple capability in browsers after decades of development is proof elites want to prevent such a thing big time (that or all browser devs are batshit stupid – in which case we shouldn't trust them with our security at all anyway).

TL;DR: Why no plain-Jane symmetric stream ciphers for web security? Because: Dystopia.

>>30706

>there was never any security in SSL in the first place, and there still isn't.

Vid Related.

Too bad Convergence wasn't widely adopted and the plugin is broken most of the time. It was just a kludgey bandaid anyway.

>>30706

>User sends resulting hash to server as a proof of knowledge.

>Server HMACs the nonce with the passphrase and compares this to the one the user sent.

>You could go to your bank in person, setup a password

Can be handy with e-commerce because, indeed, you can setup auth password in your bank along with account. But keep in mind that its not always possible to setup password in real life for every server you want encrypted connection with (in which case, anon DH will do the same).

I agree with the rest of your post - modern HTTPS is terribly designed. You can't get security remotely, over the gubberment-controlled wire without introducing any robust security leverage (visiting bank IRL in your case).

If CA architecture to be modified for security, it would require user to make a cert with his real name in it and visit CA, in this case just a notary, who will check and sign cert and vouch for its authenticity. Notary himself must be periodically re-certified by some independent international organisation to prevent fraud. Then again, such model goes against of how the Internet works, and using it would be non-anonymous huge fucking hassle.

>>30706

>>30717

>2015+x

>still using legacy banking

>>30722

I'm not going to use your Botnet™Coin™©. NO WAY!

>>30731

>Botnet™Coin™©

i lol'd. which coin is that a reference to? ripple?

>>30732

>which coin is that a reference to?

Honestly, all of them.

inb4: /cyЬеr/-zealots will stone me to death for saying this, but I wouldn't trust any of such currencies for a great number of reason.

>>30738

get this corporate drone outta here

>>30738

>I wouldn't trust any of such [crypto]currencies for a great number of reason.

care naming a few?

>>30772

hold on, this is the first anti-bitcoin shill/retard i see on fullchan. let him elaborate first, then try to get rid of him.

Bump. I thought this thread died.

>>30738

Pretty much the only reason I can think of to not use crypto (versus regular brouzouf) is instability. But you can solve that by only converting significant amounts of brouzouf right before buying.

>>28476

Why does GPG always wait for more entropy then? Every time I generate a key it hangs / waits for entropy for a while.

>>35371

>Every time I generate a key it hangs / waits for entropy for a while.

Just in case. But it hangs because you generate two prime numbers for one key. And to generate one prime you recursively pour random numbers into Eratosthenes Sieve and see if it passes as a prime, then again test that number against many other random numbers to see if it passes probabilistic test. If it does not pass, you start all over, which is fucking long operation again. And you do this two times.

bump

So when are we moving to quantum-resistant encryption algorithms?

necrolous bumpous

>>40072

why if you can use memetic associative encryption

>>25683

It's pretty neat. If you want insight into modulo and shit it's Fermat's little theorem what's at play in there