Hot answers tagged

67

An ASN.1-encoded SSH private key contains the following integers in order: The public modulus $n$ and exponent $e$; The private exponent $d$; The prime factors $p$ and $q$ of $n$; The "reduced" private exponents $d_p=d\bmod(p-1)$ and $d_q=d\bmod(q-1)$; The "CRT coefficient" $q_{\text{inv}}=q^{-1}\bmod p$. The observation that the value of $d$ in such a ...


16

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...


8

Can anyone explain why CBC-MAC is not secure for variable length message? For the previous question I'll quote Matthew Green's post from 2013: A quick reminder. CBC-MAC is very similar to the classic CBC mode for encryption, with a few major differences. First, the Initialization Vector (IV) is a fixed value, usually zero. Second, CBC-MAC only ...


7

ECC is indeed used by CloudFlare's website but only for the session key agreement. The authentication is performed using an RSA 2048 bit private key. The corresponding RSA public key is in the certificate. In other words, although ECC is being used, it is not used for authentication and therefore not part of the certificate. The ciphersuite is: ...


7

Yes, the basic idea of hardcoding a public key is secure. It is sometimes recommended as an alternative to the complexity TLS and PKI bring – otherwise it can be easy to skip a crucial step and end up with little or no security. However, the "encrypt a secret for server" scheme has some weaknesses compared to TLS. The clearest is lack of forward secrecy ...


6

Short key fingerprints are indeed vulnerable. But those are different from the short-authentication-string (SAS) used by ZRTP. A simple SAS based protocol using one-time keys could look like this: Alice sends a (collision resistant) hash of her public key to Bob. Bob sends his public key to Alice Alice sends her public key to Bob The short ...


6

My only idea is that B authenticates himself to A, because if A later decrypts it, A will see whether B was able to decrypt it. But why would you need to increment the nonce? Correct, that's the idea. If B didn't need to increment the nonce and just encrypted the same value, the message sent back would be the same that A sent, so an attacker would be ...


5

It is hard to have message authenticity without integrity. To authenticate the message you need to know what message is being authenticated. If you could change the message the authentication tag should become invalid. Message authenticity means that you can establish that the message originated from a trusted entity. For this reason message authenticity ...


4

Some background on formal key-exchange models The goal of a key-exchange (KE) is to establish a session key between two parties. Naively, we could say that a KE is secure if no adversary will be able to figure out the session key (in full) established between two honest parties. However, in formal security models we take this a bit further and insist that ...


4

I really like this question, and have two things to say. First note that CBC-MAC is no good since given the key it's easy to find a collision. Let $t$ be a tag for a message $m=m_1,m_2$ of length $\ell$ bits. Then, in CBC-MAC the input to AES first is $\ell$ and then the output is XORed with $m_1$ and input to AES, and so on. Let $t_1$ be the intermediate ...


4

The short answer is that there's no link between your physical signature and any cryptographic signature. Indeed, from the high-level description of how DocuSign works and their security manifesto there's no reason to believe that any cryptography goes into the signature process itself. Note that “signature” is an overloaded word. In this post, I will refer ...


4

Reading your message, we (in ZeroDB) realize that we need to add some things to our documentation. Provides authenticity and secrecy (most important) That one we do have now provides integrity over the whole database (no silent dropping of data) We pretty much have it at the level ZODB we base on has (ACID-compliant) leaks as less information ...


4

For high security applications using 3DES, NIST recommends using keying option 1 (all keys are different). This is simply because it's the safest. For any application, keying option 1 should be used. If you set K1==K3, then you are reducing your key size to 112 bits, which is less than the smallest key size for AES. Worse still, due to cryptanalysis done on ...


3

But if Server’s certificate is checked sucessfully by Client, how is it possible to consider that Server has been authenticated by Client, while at this time none message signed with Server’s private key has been sent to the Client and verified by it ? If only consider the key exchange to be what the RFC says it is, then yes this key-exchange can ...


3

It is very bad practice to use the same private key for two different schemes. In some cases this is secure but you need to explicitly prove it. One example of this can be seen here: http://www.pinkas.net/PAPERS/combined.ps. My suggestion is to take the Cramer-Shoup group and to define a separate key pair for DSA or Schnorr signatures. You can use the ...


3

Answering the question in your title (and not addressing your proposed alternative which I don't quite understand) there is a zero knowledge proof of password protocol "SRP" which is fast and effective. SRP does not seem to have been given as wide publicity as it should get. Having implemented it, and being an advocate of its use, I don't really understand ...


3

No, it is not safe to authenticate the BIOS in that way. CRC should be used as checksum only, i.e. to avoid random bit flips. For larger random changes you should use CRC32 at the minimum. If you want to protect against malicious change you need a cryptographically secure hash. the reason for this is that any attacker can create a malicious BIOS that ...


3

I think you're confusing some things here. The usual TLS-handshake with ECDHE (which you really should use, unless you have very good reasons) has two public keys. One of them is signed by the CA, the other one is generated on-the-fly. And before proceeding, please note: (Perfect) Forward secrecy (PFS, not security usually) only means that you don't ...


3

My question is how do I authenticate my App to the CA, to prevent something else to request these Client Certificates? There is generally no way to authenticate the client code. Any secret you embed in the app could be extracted. You must assume an attacker can send requests that an authentic client would. Instead, what you can do is authenticate the ...


3

I see 2 options that fit the requirement (small, verifiable within some limit). Because the sizes are small, the probability of the collision of a random value showing linked is high, larger values will obviously help. Option 1 is to have a random value, and encrypt or hash it, then truncate the result and concatenate to the original value. The size of the ...


3

If we assume that AES is a pseudorandom permutation (which is a standard model for block ciphers), then AES can replace the HMAC in your construction. Be aware, this only works because you have a fixed message length, i.e. the protocol must not accept nonces $> 128$bit. Besides, I guess you are aware of this but you have a shared secret key among all ...


3

This is standard Encrypt-then-Authenticate. The only difference is that when doing EtA, it actually isn't necessary to encrypt everything. This strategy makes sense when there is some part of the message that needs integrity and not privacy. In IPSec, the ICV (which is a counter to prevent replay) does not need privacy. Furthermore, by not encrypting it, it ...


3

I'll give you a hint, and you can work out the details yourself. Take any $m_1,m_2,m_3$ of length $n$ (where $n$ is the block length), with $m_1\neq m_2$. Query the oracle with $m_1$, then query the oracle with $m_2$, and finally query the oracle with $m_1\|n\|m_3$. Work through this, and you can find a message and its forgery.


3

To answer your first question, the incrementation is required in order to prevent spoofing of that message. An attacker could send back the same encrypted nonce claiming to be Bob. However, if Bob incriments the nonce and sends it back encrypted, Alice would know for sure that Bob has received the nonce and has incremented it. Now, Alice encrypting the ...


3

That doesn't hide Bob's identity from eavesdroppers. (The OP mentioned in chat that the OP isn't trying to do that.) I can no longer spot any other problems with the key exchange part. The encryption/decryption of application level data is vulnerable to arbitrary replays and reflection and dropping. ​ The public MAC input should indicate direction and ...


3

I'm answering this based on the TLS v1.2 certificate based client authentication feature. Other protocols may vary in the details. Can anybody tell me what is being sent from the user's side for getting authentication from the server? The overhead to a normal handshake consists only of the user's certificate (+ intermediate certificates eventually, ...


3

let's say I take key length of 16 bytes. Does it mean that according to wiki I must pad the key with zeros from right up to 512 bits? (block length of SHA1) Yes. opad must be a 512 bit value, like: 0x5c5c5c…5c5c....5c (512 bits)? Yes. ipad similarly: 0x363636…3636 (512 bits long) Yes. what to do with m if its length ...


3

This is prevented by: by requiring authentication of B using a private key only known to B and a public key trusted by A; by making sure that messages are protected by a message authentication code (MAC) / authentication tag, created using a session key only known to A & B. Step 2 requires a key agreement step, e.g. Diffie-Hellman or the encryption ...


3

It is secure against private key exposure but not against replay attacks by Eve. A three-way protocol avoids this, and doesn't need to use timestamps. The description below is from Delfs and Knebl's book Introduction to Cryptography. Each user, say Alice, has a key pair $(e_A, d_A)$ for encryption and another key pair $(s_A, v_A)$ for digital ...


2

I am a little confused about why it is believed to be secure against quantum attacks, couldn't the hash function be attacked? Yes, the attacker could attack the hash function, for example, by trying to find a second preimage (and there are known Merkle Signature Schemes where we can show that forging a signature can be reduced to the second preimage ...



Only top voted, non community-wiki answers of a minimum length are eligible