You've missed a key detail in how asymmetric encryption works:
For asymmetric encryption algorithms, you essentially have two keys - a "private" key, and a "public" key
If you know the private key it is trivial to calculate the public key, but the reverse isn't true - just given the public key, it is essentially impossible to calculate the private key in a reasonable amount of time
If you encrypt something with the public key you must use the private key to decrypt it, and if you encrypt with the private key you can only use the public key for decryption
This means that my server can advertise a public key, and you can use that to encrypt the traffic so that only the server that knows the private key can decrypt it
I used to know that and still struggle to understand how a handshake wouldn't allow MitM. Later I found out that it requires a third party with a trusted and known certificate for signing handshake exchange messages in order to ensure there's no man in the middle: https://stackoverflow.com/a/10496684
A big "It Depends" on that - plenty of applications of asymmetric crypto where you just hard-code the servers public key into the client and call it a day, and GPG has its own PKI scheme that is just kinda weird.
You also don't have to use Diffie-Hellman - early versions of SSL just sent the ephemeral key (the symmetric key used for the actual AES session) directly. This works, but using DH also gives you "forward secrecy" - even if a malicious third party has captured the entire encrypted session, then later steals (or factors) your private key they still won't be able to read the encrypted traffic because they can't recover the ephemeral key because it wasn't sent over the wire in the first place
Yes, that's why https needs certificates (and sometimes shows a broken lock) and why you need to accept the fingerprint when first connecting to a server via ssh.
Accepting ssh key fingerprints on first ssh is a bad practice. Ssh ca’s and or sshfp are around and have been for decades. Accepting random host keys is like trusting random self signed ssl certificates.
Use ssh ca’s for user and host keys so you can revoke and rekey hosts without having to update authorized keys. And then you can revoke access to hosts for users as well and much more.
If you know the private key it is trivial to calculate the public key, but the reverse isn't true
The public key and the private key are just two big prime numbers. The "trivial to compute" part only works once more information has been shared over the network, like it happens during key exchange. If you were to swap the prime number before initiating any contact it would work the same way.
Edit: I probably confused different encryption concepts
In RSA, the private key is a pair of big semi-primes, and the public key is derived from those numbers. I think you are confusing DHKE and RSA with your other points, the private key is never transmitted over the network. For TLS you typically use an asymmetric crypto system to validate identities and encrypt the key exchange to prevent person-in-the-middle, but the key that is agreed using that process is a symmetric key for AES or similar, but that is specific to TLS.
Also, there are other asymmetric systems that don't use primes at all - eliptic curve crypto is based on completely different math
If you know the private key it is trivial to calculate the public key, but the reverse isn't true
I didn't believe this is true... In public/private key crypto there is no such thing as "private" and "public". They're just a key pair. You choose to make one public by sharing it and the other private by not sharing it.
It depends on the cryptosystem. The private and public halves of the pair are often not symmetrical and often have overlap.
The parent is likely confused because in most situations the "private key file" will also contain all of the public key. Whether by necessity or for convenience.
Ok, semantics - for RSA you generate a private key, then derive the public key from that private key, and you could publicly post your private key if you wanted to. "Public" and "private" are just names.
But how does the encryption work if you have the public key? Since your computer knows how to encrypt the data with the public key, couldn't you use that same public key to run that algorithm in reverse? If not, since the public and private keys are not the same, how does the private key go about decrypting that data?
The actual math is way beyond me, but the algorithm is "one way" - it exploits the fact that given two prime numbers (ie, the private key) it is trivial to multiply them together, but if you only know the result (ie, the public key) it is computationally very expensive to determine the original prime factors. If you pick big enough numbers, it becomes effectively impossible to undo the multiplication
TLDW: the actual key exchange works by using massive exponents that are very fast to run to get a result, but very hard to use that result to get the exponent you started with
Great question: it's called asymmetric cryptography for a reason.
The key pair is built by the person wanting to receive private messages. The public part is made public an can be used to encrypt messages to the owner of the private key. Without it you cant read the contents.
As this method is not really performance friendly, thus method is usually used to establish a symmetric encryption key for both parties that can't be intercepted this way.
In fact: if the attacker can switch out the public key for his own during transfer, he can use it to decrypt the messages and relay them to the first party, thereby revealing all the messages. This is called a man-in-the-middle attack. This is why authentication of the key is so important. This is usually done via a trusted third party.
Sorry to be so short, I hope I have given you enough words to Google for further reading.
I don't think DH is accurately relating to this. DH key exchange is used to generate a shared secret to use symmetric cryptography by two entities from (generally temporary) private keys, which are not specifically associated with a public key (this is not a public/private key pair)
To me, two examples of public/private key usage are RSA (asymmetric cryptography) and for example SSH authentication with a key pair. DH key exchange can be used in SSH to encrypt communication, before authentication even begins
Published in 1976 by Diffie and Hellman, this is the earliest publicly known work that proposed the idea of a private key and a corresponding public key.
The multi-university and industry research team led by computer scientists at University of California San Diego will present their work at the 2024 ACM ASPLOS Conference that begins tomorrow.
Previous attacks have exploited this mechanism by analyzing entries in these tables to discern recent branch tendencies at specific addresses.
In this new study, researchers leverage modern predictors' utilization of a Path History Register (PHR) to index prediction tables.
Despite the PHR typically retaining the most recent 194 branches, the researchers present an advanced technique to recover a significantly longer history.
"This manipulation leads the victim to execute unintended code paths, inadvertently exposing its confidential data," said UC San Diego computer science Professor Dean Tullsen.
The team presents a proof-of-concept where they force an encryption algorithm to transiently exit earlier, resulting in the exposure of reduced-round ciphertext.
The original article contains 658 words, the summary contains 136 words. Saved 79%. I'm a bot and I'm open source!
I'm kinda glad this happened because I was assuming bad actors were fucking with open source stuff before the XZ stuff came out and now it's on the radar.
Though I wonder if there's any way to automate watching for stuff like this. Like the XZ backdoor involved changing what was supposed to be a bad test file, it would be nice to have a system that treats all input files as immutable and if anything needs to be processed, it goes into a separate output folder plus has a reasoning included as to why the input file needs more processing, especially something that doesn't change from system to system.
GitHub search manipulation: Attackers create malicious repositories with popular names and topics, using techniques like automated updates and fake stars to boost search rankings and deceive users.
Malicious code is often hidden within Visual Studio project files (.csproj or .vcxproj) to evade detection, automatically executing when the project is built.
The attacker had set up the stage to modify the payload based on the victim's origin, checking specifically if the victim is based in Russia. At this point, we don't see this ability activated.
The recent malware campaign involves a large, padded executable file that shares similarities with the "Keyzetsu clipper" malware, targeting cryptocurrency wallets.
The malware establishes persistence on infected Windows machines by creating a scheduled task that runs the malicious executable daily at 4AM without user confirmation.
Developers should be cautious when using code from public repositories and watch for suspicious repository properties, such as high commit frequencies and stargazers with recently created accounts.
The author's own solution is not even sufficient to meet their own criteria:
2. Hand assemble the GNU stage0 hex0 monitor (280 bytes) (or a spiritual equivalent for the SBC's ISA) from printed source assembly using pen and paper and an ISA manual.
...
6. By using the terminal to communicate with the hex0 monitor, type in more sophisticated monitors as hexdecimal after hand-assembling them on pen and paper.
The source code to these programs was obtained through requirement (2):
(2) ... You may request any of the following resources:
Source code to any open source code, printed on paper
This code does not specify that it has been signed or has had its authenticity verified. Only code received digitally through requirement (3) is cryptographically verified:
(3) ... You may request further open source code (e.g. the Linux kernel) to be delivered in some digital form ... however data delivered in this manner may only be used where:
the user can verify the cryptographic identity of that data, where that verification process itself does not rely on any data obtained using this clause, and ...
So already at the start of the process, the author is using tools to bootstrap the system which could contain backdoors.
I would change the requirements so that source code printouts are already verified by the person supplying them, or that the solver has to write their own bootstrap tools to get to the point of being able to verify cryptographic hashes/signatures before they can even use any third party source code.
Security
Hot