Hot answers tagged

63

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 ...


9

First the theoretical explanations: Integrity and authenticity are different goals to achieve, but both are achieved (for symmetric encryption) with a MAC. You should probably be using encrypt-than-MAC or an authenticated cipher unless you have very good reasons not to. No blanket statements can be made though. HMAC: HMAC is a often used construct. It ...


7

SSL was designed long ago when encrypt-then-MAC wasn't that popular yet. Even TLS 1.2, published in 2008, is pretty old by now, and while encrypt-then-MAC was preferred by then, the practical risks were underestimated for a long time. Padding oracles attacks became well known after several high profile attacks in 2010. With stream ciphers, MAC-then-encrypt ...


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: ...


6

SRP does DH key exchange with authentication, and has the capability to also authenticate the server as well (though usually the server is authenticated by keeping the verifier secret). If the key is generated strictly from a password and salt, with the salt stored on the server, you can do a dictionary attack on the verifier (e.g. if the server is ...


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 ...


5

In summary: Yes, HMAC is the way to go for construction of a MAC from an arbitrary concrete iterated hash. We have no constructive argument of security of the MAC constructs in the question; we even have a concrete attack when using some otherwise apparently fine hashes. I consider a hash constructed by iterating a compression function $F$ as ...


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

The authentication tag is defined as an output parameter in GCM (see section 7, step 7 of NIST SP 800-38D). In all the API's I've encountered it's appended to the ciphertext. Where it is actually placed is up to the protocol designer. The protocol designer may well consider the place behind the ciphertext as ad hoc default though. The name "tag" of course ...


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

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

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

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

Having a client (ex. your web browser) use zero-knowledge proofs to authenticate itself to a server only makes sense if the server knows about the client's public key in advance, and if the client keeps the same private key forever. So you could have the client-side generate a keypair when you register your account, and the server records your public key ...


3

I would think these numbers would have been put on the google search engine, and yield (probably) many hits. This assumption is wrong. Certificate serial numbers are not indexed by common search engines, nor are they typically posted to any HTML site. Frankly, I'm not sure why you would assume they'd be indexed. The Wordpress certificate is used for ...


3

I'm going to agree with @fgrieu's marvelous post above in a back-handed way. My answer is: No, you don't have to use an HMAC. Do it anyway. As you noted, some hashes, sush as SHA-3 (especially in its Keccak form), Skein (which I was a team member on), and others will work just fine. In the case of Skein, there is a one-pass Skein-MAC that has a proof of ...


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

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

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 ...


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

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 ...


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

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, ...



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