New answers tagged

1

Public key encryption uses a public key of the receiver; anybody can encrypt. So origin authentication would only work if you'd also have a shared secret key (in which case the whole public key encryption becomes kind of useless) or a private key (in which case you'd probably use a signature or an authenticated key agreement protocol).


0

Reffering to the question provided by me: "Where and how to store private keys in web applications for private messaging with web browsers?" which means that I want to find a bullet proof mechanism to permanently store and protect public keys in web-browser for end-to-end encrypted messaging without needing more than: web-browser HTTPS support javascript ...


3

The master key has to be stronger in the sense that it's more sensitive than session keys. The information used to derive session keys are not necessarily secret, so if it's easy to recover the master key, an attacker will be able to compute all the derived keys. On the other hand, recover a single session key will not help you to recover the master key ...


0

Cookies? You could store users private keys in a cookie only your website could access. The public keys you could store on your server, so anyone that wants to send a message could do so. And the encryption and decryption happens in JavaScript. That way there is no risk if your server is hacked. EDIT: As a soloution to dandavis problem, you could solve it ...


5

Yes, kind of. The encoding does depend on the individual bits so there could very well be timing differences. Note that the differences would be pretty small; encoding a byte is likely much faster than e.g. modular exponentiation. But as even block ciphers are vulnerable it may very well be possible, especially since table lookup may be implemented. The ...


1

I am using 32 character long random alphanumeric strings as the cryptographic keys First, I would suggest generating the keys differently. Cryptographic keys are not like passwords. There are specific requirements for the format of a cryptographic key, which depends on the algorithm. In the case of AES, HMAC, and most other symmetric algorithms, the ...


1

Hashes and therefore HMAC do not take alphanumeric characters as input. You'd first have to convert the textual "key" into bits. I've put "key" in quotes because keys for HMAC should consist of bits in the first place. The recommendation for HMAC is (indeed) that the key size is identical to the output size (and the intermediate state for Merkle–Damgård ...


2

I am trying to better understand authentication. Lets say I have posted my 128-bit AES symmetric key on some forum, encrypted asymmetrically to my friend using 256-bit ECC (25519). The forum isn't controlled by us so this key message could potentially be tampered with. Well first of all, note that encrypting with curve25519 isn't as trivial as ...


1

If the key is send beforehand it is not required but highly recommended to sign it. Otherwise anybody could post an AES key, encrypted using the public encryption key of your friend. In that case your friend may only find out after receiving the right messages. Furthermore, your friend may not be able to distinguish between an invalid key and an invalid ...


0

DEK (data encryption key): The key that encrypts the actual content. The DEK gets changed less often than the KEK (see below). KEK (key encryption key): The key that encrypts the DEK. The KEK gets changed ("rotated") at regular intervals according to best practices and company security policies. As the volume of content grows, the more arduous it will be ...


0

Everything that Maarten has said is true; however I would emphasize one point that may not be obvious. I'm pretty sure you've doing things correctly; however it would be prudent to say it anyways. CMAC is a good KDF is the key is unknown, and the message being MACed is known. It is not a good KDF if the key is known, and the message is unknown. That is, ...


4

CMAC(masterKey, i) should generally suffice, yes. Note that you would need to specify an encoding for i (e.g. octet string consisting of the big endian encoding of i, left-padded with zero valued octets up to 4 octets). It's probably better to implement one of the schemes defined in NIST SP 800-108: "Recommendation for Key Derivation Using Pseudorandom ...


10

There is no such thing as a 16 bit AES key. AES is a block cipher with a block size of 128 bits and a key size of 128, 192 or 256 bits. As a block cipher, AES can only encrypt 16 bytes (128) bits at a time. AES in itsef is not (CPA) secure as repetition of the plaintext would lead to repetitions of the ciphertext. To encrypt larger amounts of data, AES ...


2

I wanted to help break down exactly what you're seeing. If you take your base64 string: MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCqGKukO1De7zhZj6+H0qtjTkVxwTCpvKe4eCZ0FPqri0cb2JZfXJ/DgYSF6vUpwmJG8wVQZKjeGcjDOL5UlsuusFncCzWBQ7RKNUSesmQRMSGkVb1/3j+skZ6UtW+5u09lHNsj6tQ51s1SPrCBkedbNf0Tp0GbMJDyR4e9T04ZZwIDAQAB You then decode it into hex: 30 81 9F 30 0D 06 ...



Top 50 recent answers are included