There's a few different things here.
a public key is the product of two large prime numbers
That is partially true for RSA, though RSA public keys also contain an additional integer (e, in the algorithm's description). Other public key algorithms, and even public key ciphers, do not work the same way (see ElGamal Encryption, for example.)
as long as ...
In simple terms, RSA encryption is a trap-door function: easy to calculate in one way, hard in reverse.
Chiphertext is generated by using modulo operation on a result of the computation involving public key and the message.
message = 123
result of the computation = 1234567890
ciphertext (result of the computation modulo 1000) = 890
The numbers in the ...
Someone is trying to log in. That means they've provided two things:
Who they claim to be.
Something they claim proves they are that person.
The salt should be tied to #1, as it's unique per user (and globally, but especially unique within your own database). Then you can just look up the user's information in your database, and the salt will be part of ...
In the TPM specifications, an SRS key is a public-private key pair, the private key is kept inside the TPM and the public segment is available to wrap working keys. SRS keys are used as the proxy for the EK key in all transactions outside of the TPM, with only the public segment being used outside of it.
Thats whats in the docs. Now, how vendor's ...
It's not. WPA-Enterprise and WPA-PSK will ultimately create a PTK key to be used in the TKIP algorithm, because it is WPA, therefore less secure than WPA2, whether it is WPA2-PSK or WPA2-Enterprise.
Enterprise just offers encryption for the 4-way handshake, such as PEAP, or use of certificates, so WPA-Enterprise is arguably more secure than WPA-PSK but will ...
Moved from the question to an answer.
This was very simple to check, I just changed the IV to be the correct
length and the ciphertext remained the same. Hence, the extra byte is
not used in the algorithm and somebody miscounted.
/* A 128 bit IV */
unsigned char *iv = (unsigned char *)"...
Is it possible to obtain this functionality?
No. In fact, having this functionality would make your hash trivially reversible.
Imagine that there is some row that an attacker wants to reverse the hash for. They can:
Perform a search for every letter alone (e.g. "A" … "Z"), and check which one of those searches returns the row they are looking for
No, you cannot do it.
You want your salts to be long, random or random-like, and unique. Otherwise, an attacker can make a rainbow table for your database based on the salt. Then you will fall victim to targeted precomputation.
No, this is not possible with hashes. Hashes are specifically designed to prevent this, otherwise attacker wanting to obtained the hashed value could start by checking first letter, then the next...
Also, you are likely using salt wrong.
Diffie Hellman, RSA, and ECC are all ways to implement asymmetric cryptography (not only encryption but digital signatures and key exchange). There are also additional ways to implement asymmetric cryptography, for example the active research on post quantum crypto.
For actual specific questions ...
I would like to remind you that:
the base64 fingerprint calucuated by ssh-keygen will:
SSH by convention omits any trailing padding (the padding =s)
see my question here https://stackoverflow.com/questions/56769749/calculate-ssh-public-key-fingerprint-into-base64-why-do-i-have-an-extra
I performed frequency analysis and found a shallower distribution than I would expect for a monoalphabetic ciphertext of this size. Might indicate a polyalphabetic, homophonic, or polygraphic substitution cipher. These are just a few possibilities.
You can learn more about frequency analysis and its relevance to cryptanalysis here and here.
I would start ...
Just to add-on to your third question, key rotation can mean different things in different contexts. When using a key management system, key rotation means generating a new key to be used for future encryptions; but the old keys remain in the system and are preserved for decryption. All encrypted data is tagged with the identity of the key used to encrypt it,...
This question is both too broad and too narrow, but I'll see what I can do.
Your understanding about AES block and key sizes is correct.
Usually, yes, you'd want to use a cryptographically secure (P)RNG to generate encryption keys (for any cipher, AES included). However, there are times when this isn't practical, such as when a human needs to be able to ...