There are 5 security levels 80, 112, 128, 192 and 256. The q size is twice
that. P is 1024, 2048, 3072, 8192, 15360. There are also p of 4096 and 6144
assessed as 128.

This way madness lies.

The best way to design a crypto protocol which guards against
incompetent implementation is to make it easy to get right. Asking
one end to check the competence of the other end is a lost cause; you
will add enormous complication to that end and only check for a small
class of errors, and the complexity of the implementation is
increased, which increases the chance of error overall.

No, the only time I'm going to check that group parameters were fairly
generated will be when you ask me to generate a public key using
parameters you specify.

I don't think we were referring to checking the
group parameters. We were referring to checking

"Gregory G Rose" <ggr@qualcomm.com> wrote
I don't think we were referring to checking the
group parameters. We were referring to checking

I think Don wanted to check the group parameters.

There is no reliable way to check either her competence or her
parameters. It is possible to construct weak DSA parameters, but
she would have to do so willfully.

There are a number of attacks, particularly on
Diffie-Hellman, where a MITM can feed you bad
parameters in such a way that can break the
system. These checks are not optional.

"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote
I thought FIPS pub whatever said 512-1024 bits. Although you could
make the big field larger anyway, the small field is still normally
160 bits, so you might not gain from making the big field bigger.

You can make both parameters as large as you like. See IEEE-1363.
The largest discrete logs in a non-special field that anyone has done
were only about 400 bits, so 1024 bits is plenty secure for most
purposes anyway.

There are a number of attacks, particularly on
Diffie-Hellman, where a MITM can feed you bad
parameters in such a way that can break the
system. These checks are not optional.

I don't think we were referring to checking the
group parameters. We were referring to checking
which subgroup the D-H public key belonged in.
(That's if I'm remembering the thread correctly.)
This is a necessary check.

The way aNSI X9 and NISt words it is that one needs assurance of validity
of DP
and public keys. If one has no assurance or if one knows they are
invalid,
then one should not use them. There are various ways assurance can be
provided.

My scenario was that someone gave me a new set of DP. My choice would be
to
ensure the DP are good arithmetically (i.e., meet the standard's spec),
that
is, not solely rely on the other user's system to do it right. It is
straightforward to check. There can be HW errors, SW errors,
intermittent
errors, user errors and errors introduced by an adversary. One can hope
or
one can check or one may have other means of assurance. Hoping in this
biz
does not seem right to me.

The way aNSI X9 and NISt words it is that one needs assurance of validity of DP
and public keys. If one has no assurance or if one knows they are invalid,
then one should not use them. There are various ways assurance can be
provided.

My scenario was that someone gave me a new set of DP. My choice would be to
ensure the DP are good arithmetically (i.e., meet the standard's spec), that
is, not solely rely on the other user's system to do it right. It is
straightforward to check. There can be HW errors, SW errors, intermittent
errors, user errors and errors introduced by an adversary. One can hope or
one can check or one may have other means of assurance. Hoping in this biz
does not seem right to me.

My scenario was that someone gave me a new set of DP. My choice would be
to
ensure the DP are good arithmetically (i.e., meet the standard's spec),
that
is, not solely rely on the other user's system to do it right.