“Randomly derived” is not standard phrasing and I suspect that it isn't what the author meant to write. From context, what is necessary here is to have a distinct key for each message. This can be achieved either by randomly generating a key (I think that's what the author meant to write) or by deriving a key using a key derivation function with a unique ...
A simple algorithm for secure HMAC implementation
Generate random clientid, clientsecret (32-bytes), hmacKey (64-bytes)
Encrypt hmackey using AES256 with clientsecret as the key to get enc_hmacKey
Server stores clientid and enc_hmacKey
Client will be provided with clientid,clientsecret and hmacKey
HMAC will be computed ...
If you used the randomly generated keystream bit $k[i]$ twice (think of it as a random variable, uniformly and independently generated at time $i$) at positions $i,i+\tau,$ then you'd have
c[i]=p[i] \oplus k[i]
c[i+\tau]=p[i+\tau] \oplus k[i],
then adding the ciphertext bits would yield the plaintext bit "difference"
No. It simply means that any bit at position $i$ in the stream is only used once. So what ever value bit $i$ is in the key, it's xored with the equivalent positional bit in the plain text to create the cipher text. As: c[i] = p[i] XOR k[i]. On a computer, you'd be using octets rather than bits. Your 2nd part is explained then knowing this. And yes to ...
AES doesn't require uniformly distributed keys. However, if you have a key with less than 256 bits of entropy, then naturally your keyspace will be smaller than the maximum. Whether or not this is an issue depends on just how few bits you have. The only time a non-random key is bad for AES is when it's chosen very specifically to be harmful, in which case it ...
Very generally(!) AFAIK:
Step 4 ("-Server uses...") should be: Client creates a key S and uses server's public key to encrypt S and send it to the server, after which S is used as a symmetric key by both.
I'm assuming you're talking about RSA. The more common DH algorithm uses ephemeral public and private keys generated by both the server and the client, although that's not relevant to this answer. The public and private keys are not used to exchange traffic. Instead, they're used to exchange a symmetric key which is used to encrypt data going both directions....
The first question you should ask yourself is what you are trying to protect against. AES-256 is even considered secure against quantum computers. Certainly a brute force attack is already far out of reach. So if AES breaks it is likely because the algorithm is broken. In that case neither of your schemes may save you; you would have been better off using an ...
Cryptographic security is not a one-dimensional spectrum. Increasing the key size increases keyspace, which is the maximum number of possible keys that must be iterated through to complete a brute force attack. Increasing rounds, on the other hand, reduces the chances that novel cryptanalysis, which allows an attacker to break the cipher faster than brute ...
A Bad Answer For Dummies / Web Developers
I'm going to give a bad answer to this for the types of people like myself who aren't mathematicians, but who could reasonably solve FizzBuzz or calculate a Fibonacci sequence.
You can't do this without a library (at least not as far as I can tell).
A Mix of Terms
d vs $k$, $a$, and $b$
d is the private ...