= Public-key cryptosystem
{parent=Public-key cryptography}
{tag=Cryptosystem}
= RSA
{disambiguate=cryptosystem}
{c}
{parent=Public-key cryptosystem}
{wiki}
Based on the fact that we don't have a algorithm for as of 2020. But nor proof that one does not exist!
The private key is made of two randomly generated prime numbers: $p$ and $q$. How such large primes are found: .
The public key is made of:
* `n = p*q`
* a randomly chosen integer exponent $e$ between `1` and `e_max = lcm(p -1, q -1)`, where `lcm` is the
Given a plaintext message `m`, the encrypted version is:
``
c = m^e mod n
``
This operation is called can be calculated efficiently with the .
The inverse operation of finding the private `m` from the public `c`, `e` and $n$ is however believed to be a hard problem without knowing the factors of `n`.
However, if we know the private `p` and `q`, we can solve the problem. As follows.
First we calculate the . TODO continue.
Bibliography:
* https://www.comparitech.com/blog/information-security/rsa-encryption/ has a numeric example
= How large primes are found for RSA
{parent=RSA (cryptosystem)}
* https://crypto.stackexchange.com/questions/1970/how-are-primes-generated-for-rsa
* https://crypto.stackexchange.com/questions/690/can-i-select-a-large-random-prime-using-this-procedure/693#693
Answers suggest hat you basically pick a random large odd number, and add 2 to it until your selected passes.
The tells us that the probability that a number between 1 and $N$ is a prime number is $1/log(N)$.
Therefore, for an N-bit integer, we only have to run the test N times on average to find a prime.
Since say, A 512-bit integer is already humongous and sufficiently large, we would only need to search 512 times on average even for such sizes, and therefore the procedure scales well.
= RSA vs Diffie-Hellman
{c}
{parent=RSA (cryptosystem)}
vs are the dominant systems as of 2020, so it is natural to ask how they compare:
* https://security.stackexchange.com/questions/35471/is-there-any-particular-reason-to-use-diffie-hellman-over-rsa-for-key-exchange
* https://crypto.stackexchange.com/questions/2867/whats-the-fundamental-difference-between-diffie-hellman-and-rsa
* https://crypto.stackexchange.com/questions/797/is-diffie-hellman-mathematically-the-same-as-rsa
As its name indicates, is a algorithm. TODO verify: this means that in order to transmit a message, both parties must first send data to one another to reach a shared secret key. For RSA on the other hand, you can just take the public key of the other party and send encrypted data to them, the receiver does not need to send you any data at any point.
= Diffie-Hellman key exchange
{c}
{parent=Public-key cryptography}
{wiki=Diffieâ€“Hellman_key_exchange}
= DHKE
{c}
{synonym}
{title2}
Based on the fact that we don't have a

algorithm for the as of 2020, but we do have an efficient algorithm for . But nor do we have proof that one does not exist! Living on the edge as usual for .
= Key exchange
{parent=Diffie-Hellman key exchange}
= Elliptic curve cryptography
{parent=Public-key cryptography}
{tag=Elliptic curve}
{tag=Discrete logarithm}
{wiki}
= Elliptic-curve Diffie-Hellman
{c}
{parent=Elliptic curve cryptography}
{tag=Diffie-Hellman key exchange}
{wiki}
= ECDH
{c}
{synonym}
{title2}
The algorithm is completely analogous to in that you efficiently raise a number to a power $n$ times and send the result over while keeping $n$ as private key.
The only difference is that a different group is used: instead of using the , we use the of an .
\Video[https://www.youtube.com/watch?v=NF1pwjL9-DE]
{title= by (2018)}
{description=https://youtu.be/NF1pwjL9-DE?t=143 shows the continuous group well, but then fails to explain the discrete part.}
Variant of based on .
= Diffie-Hellman vs ECDH
{c}
{parent=Elliptic-curve Diffie-Hellman}
https://crypto.stackexchange.com/questions/29906/how-does-diffie-hellman-differ-from-elliptic-curve-diffie-hellman
has smaller keys. https://youtu.be/gAtBM06xwaw?t=634 mentions some interesting downsides:
* bad curves exist, while in modular, any number seems to work well. TODO why?
* TODO can't find this mentioned anywher else: has a proof that there is no algorithm, doesn't. Which proof?
= Encryption
{parent=Cryptography}
{wiki}
= Encrypted
{synonym}
= Steganography
{parent=Encryption}
{wiki}
= Steganographically
{synonym}
= Deniable authentication
{parent=Encryption}
{wiki}
= End-to-end encryption
{parent=Encryption}
{tag=Good}
{wiki}
= E2EE
{c}
{synonym}
{title2}
= End-to-end encrypted
{synonym}
= Forward secrecy
{parent=Encryption}
{wiki}
= Perfect forward secrecy
{synonym}
https://stackoverflow.com/questions/20505942/how-does-perfect-forward-secrecy-pfs-work/66118134#66118134
= Disk encryption
{parent=Encryption}
{wiki}
= Can a smartphone's PIN or password be brute-forced in an offline attack?
{parent=Disk encryption}
https://security.stackexchange.com/questions/202174/can-a-smartphones-pin-or-password-be-brute-forced-in-an-offline-attack
has a hard time understanding why this is possible, e.g. many people use short 4 digit pins, or a short swipe pattern. Why can't this be cracked easily offline?
= Linux Unified Key Setup
{c}
{parent=Disk encryption}
{wiki}
= LUKS
{c}
{synonym}
{title2}
= Disk encryption password handover plausible deniability
{parent=Disk encryption}
{wiki}
* https://security.stackexchange.com/questions/135846/is-plausible-deniability-actually-feasible-for-encrypted-volumes-disks
* https://security.stackexchange.com/questions/87153/linux-plausibly-deniable-file-system
Can we do better than "wrong password implies random bytes"?
Can the last disk access times be checked via forensic methods?
= GNU Privacy Guard
{c}
{parent=Cryptography}
{tag=GNU package}
{title2=GnuPG}
{title2=GPG}
{wiki}
Generate public private key, test encrypt and test decrypt:
``
# Create your pubkey.
gpg --gen-key
gpg --armor --output pubkey.gpg --export
# Encrypt using someone's pubkey.
gpg --import pubkey2.gpg
echo 'hello world' > hello.txt
gpg --output hello.txt.gpg --encrypt --recipient hello.txt
# Double check it is not plaintext in the encrypted message.
grep hello hello.txt.gpg
# Decrypt.
gpg --output hello.decrypt.txt --decrypt --recipient hello.txt.gpg
diff -u hello.decrypt.txt hello.txt
``
= Internet privacy
{c}
{parent=Cryptography}
{wiki}
= Anonymity
{parent=Internet privacy}
{wiki}
= Anonymous
{synonym}
= Anonymously
{synonym}
= Internet privacy organizations
{parent=Internet privacy}
= Riseup
{c}
{parent=Internet privacy organizations}
{wiki}
= Operations security
{parent=Internet privacy}
{wiki}
= Operational security
{synonym}
= OPSEC
{c}
{synonym}
{title2}
= Tor
{disambiguate=anonymity network}
{c}
{parent=Internet privacy}
{wiki}
= Tor Browser
{c}
{parent=Tor (anonymity network)}
{wiki}
= Onion service
{c}
{parent=Tor (anonymity network)}
{wiki=https://en.wikipedia.org/wiki/Tor_(network)#Onion_services}
= Tor Onion service
{c}
{synonym}
= Tor hidden service
{c}
{synonym}
= Onion hidden service
{c}
{synonym}
This is a way to host a server that actually hide the of the server from the client, just like hides the of the client from the server. Amazing tecnology!
This is why it enables hosting things like the : is not able find where the server is hosted, and take it down or identify the owner.
Bibliography:
* https://security.stackexchange.com/questions/38194/how-can-i-get-the-ip-address-for-a-tor-hidden-service-hs-with-a-onion-address
= Dark web
{parent=Onion service}
{wiki}
= Hidden Answers
{parent=Onion service}
{wiki}
https://www.reddit.com/r/onions/comments/sfquss/hidden_answers_is_back/ gives pbqttnffb5sh6ckgnz4f5by55w25gd6tuw5f5qcctmnyk62eyhgx6rad.onion which is Dead Janary 2024
= Onion service search engine
{parent=Onion service}
= Uncensored Onion service search engine
{parent=Onion service search engine}
This is where "fun" stuff is likely to be.
= Tor.link
{parent=Uncensored Onion service search engine}
https://tor.link/
Live January 2024.
= The Hidden Wiki
{c}
{parent=Tor (anonymity network)}
{wiki}
= Can ISPs deanonymize Tor users based on timestamps of public posts?
{parent=Tor (anonymity network)}
{wiki}
https://security.stackexchange.com/questions/237632/can-isp-deanonymize-telegram-public-channel-creators
= Ciphertext, plaintext, key and salt
{parent=Cryptography}
= Ciphertext
{parent=Ciphertext, plaintext, key and salt}
{wiki}
= Key
{disambiguate=cryptography}
{parent=Ciphertext, plaintext, key and salt}
{wiki}
= Pre-shared key
{parent=Key (cryptography)}
{wiki}
An overview of what you can do with a pre-shared key with tradeoffs can be found at: https://quantumcomputing.stackexchange.com/questions/142/advantage-of-quantum-key-distribution-over-post-quantum-cryptography/25727#25727 The options are:
*
*
* authentication with some protocol
= Message authentication code
{parent=Pre-shared key}
{wiki}
Bibliography:
* https://crypto.stackexchange.com/questions/59958/is-it-safe-to-hash-a-packet-with-a-shared-secret-to-prove-authenticity
= Man-in-the-middle attack
{parent=Cryptography}
{wiki}
= Man-in-the-middle
{synonym}
= MITM
{c}
{synonym}
{title2}
= Authentication
{disambiguate=cryptography}
{parent=Man-in-the-middle attack}
In the context of cryptography, authentication means "ensuring that the message you got comes from who you think it did".
Authentication is how we prevent the .
Authentication is one of the hardest parts of cryptography, because the only truly secure way to do it is by driving to the other party yourself to establish a so you can do . Or to share your with them if you are satisfied with the safety of .