# Tag Info

0

I would like to know what can possibly go wrong when generating custom groups for use as Diffie-Hellman parameters. Aside from the mathematical issues that others have described, if you generate a parameter yourself, you need to convince the other party that you're exchanging keys with that the parameter that you have given them is actually a prime ...

2

One requirement that you don't have listed is that the generator $g$ needs to generate a subgroup that's of a large prime order; here's what can go wrong if that is not true: If the order of $g$ (which we call $q$) has a factor $r$, then the attacker can, hearing $g^x$, determine $x \bmod r$ in $O(\sqrt{r})$ time. If $r$ isn't large, this immediately ...

1

One consideration might be to generate a group so that the prime modulo p can be written in the form: $$p = 2q +1$$ Where $q$ is prime. Since every subgroup of $Z_p$ has order $a$ such that $a|p-1$ the only possible subgroups of this group have order either 2 or $q$. Then you can use a generator for the subgroup of order $q$.

0

Your question is not quite not easy to understand, but I'll give an answer to the following interpretation of your question: How is ECDH used in ECDSA? Or differently formulated: How to build an ECDSA signer and verifier from ECDH? I'll follow the documentation (and strip) the documentation from Wikipedia here. First, compute the public key ...

0

You're right, it seems like there is a typo in Step 4. The MAC Slave Key should be encrypted with the MAC Master Key, as that is the information that is shared between partners. This is alluded to in the parenthetical, noting that only the partner has the Master Key to decrypt it.

5

The SNI extension is plain text in the ClientHello. This means that it is possible to passively snoop the value and redirect the traffic. This is already used in practice, i.e. haproxy has this feature for several years.

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

1

You can use ephemeral Diffie-Hellman and then use RSA to authenticate the parameters and established key seed the same way as TLS does. Java Card implementations usually contain an implementation of ECDH key agreement. An advantage is that you don't need very large key sizes to be reasonably secure. Furhtermore, ECDH operation and key pair generation is ...

1

Both RSA and DH have a similarity which is the Modulus Exponential (modexp) function (RSA encrypt/decrypt function). Since both RSA and DH uses the same modexp function, you can make full use of the Cipher for ALG_RSA_NOPAD in JavaCard's crypto API. I have sat down and taken time to adapt the RSA crypto functions for traditional non-ECC type of DH functions ...

1

Diffie-Hellman relies on a mathematical problem on positive integers. To use it with bytes you just have to convert the bytes to - or use the bytes as - an integer. Usually this would be a unsigned big-endian (or network order) integer. For Diffie-Hellman the parameters consist of the modulus and the base. The public value could be 1024 bits (128 bytes). ...

0

what I was originally thinking of was a way to compress random data. this compression data could be encrypted using one-time-pad and then used as a key. the approach of that is impractical. I have new approach to infinite one-time-pads. in every message include a reference to a randomly picked public file(s). encrypt said files to produce higher entropy ...

Top 50 recent answers are included