17

Is it possible to securely transfer random values in such a way that they are still viable for use in cryptography? Yes and this is done all the time. If you use a TLS_RSA cipher suite, the client uses RSA to encrypt key material, i.e. random values, and transfer that securely to the server for key derivation. The owner of the random.org service ...


15

Most likely, this 'shared secret' was actually an IKE "preshared key"; it is used to authenticate the two sides (and, for IKEv1, is stirred into the keys). It actually isn't used as a key (and hence someone learning that key cannot use it to listen in, unless they perform an active Man-in-the-Middle attack). I suspect the password is the authentication ...


12

Ideally, you should not use any of them. At all. Here's why. RC4, MD5 and DES should not be used anymore. Old crypto. Toss it. CBC mode in AES sometimes suffers from implementation problems (cf. Padding Oracles). Thus, CBC should be avoided. SHA1 is considered insecure and is not be accepted as a certificate signing hash since January 2017 by major browsers....


11

RC4 sucks. 3DES sucks too, but a bit less than RC4. AES does not suck. The "CBC" part is kinda sucky, but less than 3DES (which has CBC too anyway) and it can be fixed with proper implementations. DHE provides forward secrecy, a highly fashionable but somewhat overhyped property. It's nice to have, unless it comes with undesirable side effects. In your ...


10

None of them are optimal, but only the RC4 ones are clearly broken. RC4 has been deprecated and should be disabled (see RFC 7465). Both 3DES and AES are fine, though the latter is preferable in practice due to its speed and larger block size. Suites with DHE_DSS are preferable over plain RSA (when keys and parameters are of sufficient size) because they ...


9

There is no such thing as the most secure curve. For one you can always come up with a larger curve if you need one. For another there are many measures of security and not all curves are directly comparable. If you wanted the curve for which the current best known attack is the slowest, then by that measure sect571k1 is actually the most secure out of the ...


8

There are two facets in the use of TLS-1.0 with TLS_RSA_WITH_RC4_128_MD5. From a cryptographic point of view: TLS-1.0, as a protocol, is not broken. It does a number of things in a suboptimal way, forcing implementations to jump through intricate and topologically improbable hoops in order to avoid side-channel leakages. Recent implementations ought to be ...


8

The short answer is ‘for forward secrecy’, but that glib term obscures the meaning of the property we hope for. Suppose Alice sends a message to Bob. If Alice and Bob both erase the message, what is the time at which all key material that can ever decrypt a transcript of network packets on the wire is erased? Without prekeys, the following are all the ...


6

For information theoretic security in Shamir's [m,m] secret sharing scheme, do i need both authentic and confidential channels? Regular shamir secret sharing provides no protection against modified shares. So we typically assume an honest dealer with authentic and confidential channels. That means the adversary cannot change the message in transit. If a ...


6

If no one-time keys are used, the passive side of the key agreement just uses two keys: The identity key $IK_B$ and the signed prekey $SPK_B$. The identity key is a long time key, the signed prekey can be used longish, too since they only have to be updated at some interval. This setting doesn't guarantee you a real forward secrecy, since an attacker ...


5

Registration phase/process it is always assumed that communication is over the secure/private channel, whereas, all of the phases communication is happening over the public/open channel. What is the reason for this? Well, the point of the registration phase is to register the client to the server, so that they can reach mutual authentication ...


4

You might want to look at Ed448-Goldilocks, a new 448-bit Edwards curve that has been approved for use in standards like TLS by the CFRG, designed "as an alternative to both secp384r1 and secp521r1": https://eprint.iacr.org/2015/625.pdf


4

Beyond weaknesses in specific curves, it is hard to give a scientific answer to this. Personally, I am quite conservative. I always prefer prime curves over binary field curves. I also think that the NIST curves P-256 and so on have been around long enough to give us strong confidence. (And they are fast enough for most applications.)


4

The main misconception is, that Shamir's secret sharing is not a protocol. It states: If you have enough shares, then you can retrieve the information. And it is information theoretic. Waht does this mean? First off, there is no adversarial model in the sense of malicious or honest-but-curious adversary. It is out of scope of the protocol how and if these ...


4

Is it correct to use MAC instead of HMAC for short? In general, no. MAC is a much more general concept than HMAC and thus such an equivalence in saying is clearly inacceptable. However, if you are talking about a specific protocol which authenticates its payload, saying "the MAC" to designate the MAC algorithm or the tag for messages, even if they use HMAC, ...


4

The problem is that the session keys within TLS are bound to the TLS session. If you just generate your own keys then that particular binding is lost. You might be able to hack or retrieve information from the TLS session to bind it again, but that would be rather like hacking. Establishing the keys yourself will very likely lead to a significantly worse ...


4

For this I attach a CRC-32 checksum of the message with the message counter, which is increased after every message sent. Bad Idea. This still allows anyone to arbitrarily flip bits in the plaintext (by flipping the corresponding bit in the ciphertext, and figuring out which bits flip in the CBC; this is a trivial computation that can be done instantly) ...


4

As indicated in Forward Secrecy Article of Wikipedia; In cryptography, forward secrecy (FS), also known as perfect forward secrecy (PFS), is a feature of specific key agreement protocols that gives assurances your session keys will not be compromised even if the private key of the server is compromised. Forward secrecy protects past sessions against ...


4

You're confusing a lot of things: Alice and Bob agrees on a shared private key that is to be used to encrypt You cannot have a "shared private" key; sharing and keeping things private are opposite terms. That would be called a secret key, as it is kept secret between Alice and Bob (some books confuse these terms as well, but yeah). To reach private ...


4

What you are doing sounds like piling on complexity of dubious value without a clear understanding of what security the components actually provide, in the hope that enough complexity will render the question moot. I would advise you discard the hare-brained scheme you've cooked up and start from something much simpler that is easier to prove theorems about....


4

Online $\neq$ Synchronous Yes, Noise can be used in a somewhat asynchronous setting. Noise is initially meant to be an "online" protocol to establish secure channels, however "online" here does not really imply it requires a "fully synchronous network", but more like a "reliable channel" in which packets will come in ...


3

No. A CRL is as public as the certificate it revokes; it has to be signed to guarantee authenticity, but not encrypted. There are no optional confidentiality requirements for CRL distribution in RFC 5280. It is not even common practice to use anything other than plain http for the CRL distribution points. The whole idea with CRLs is to get them out there to ...


3

TL;DR: It allows the parameters to be backdoored and the solution is a simple primality test. What exactly is a composite group [and why does it matter]? First, we need to get a quick understanding of the Diffie-Hellman Key-Exchange. Diffie-Hellman (DH) works on a mathematical construct named group, which is a set and an operation which adhere to some ...


3

As far as I know, if PRF are used, then it is HMAC not a MAC. Well, first off, HMAC is a type of MAC. A MAC is a cryptographical primitive with certain security properties (approximately, if you don't know the key, then it's hard to predict the output for any given input). HMAC is a specific design that yields a MAC; it uses a hash function internally. ...


3

Your idea lacks forward secrecy, which protocols like TLS often (in newer versions anyway) offer. Otherwise it is close to how such things are usually done. To get forward secrecy you would instead use an ephemeral Diffie-Hellman key exchange, which you would authenticate with the pre-shared public key (which would be a signing key, not an encryption key, ...


3

Alice uses Alice's private keys and Bob's public keys. Bob uses Bob's private keys and Alice's public keys. The notation DH(A, B) means that you combine whichever private key you know between A and B with the public key of the other. So, when Alice computes DH(IKa, SPKb), she uses the private part of her long-term identity key IKa and the public part of ...


3

No if strictly they have no prior knowledge and no secondary secure channel to exchange information. Man in the middle attack will always be possible in this case because the two parties cannot authenticate each other. If they cannot authenticate, then even if they have a value at the end, the value may not be secret nor shared with the right party.


3

Key encapsulation or key wrapping is the encryption of a key with another key. There may be a symmetric key or asymmetric key pair that encapsulates the key destined for transportation; this key can then be called a key transport key. Key transportation is simply the secure transportation of a key. For public keys you'd expect integrity and authenticity - ...


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