Hello,
I just began approaching the cryptography issues from a developer
standpoint and I have some newbie questions to submit. Sorry for being
too obvious.
1) I made some test using the examples in the SDK documentation about
java.security showing how to sign and verify messages.
I tried the SHA1withDSA signing algorithm.
Is the length of the signature generated by SHA1withDSA fixed (dictated
by the algorithm itself)?
I'm asking because printing the length of the array of bytes assigned
through:
byte[] sig = dsa.sign();
where dsa is a Signature object I get values of 46 or sometimes 47 in
sig.length !?
Am I missing something or the signature lenght is not constant or
there's some byte padding involved?
2) I want to use a PKI model to sign database records but I do not want
to store the key pairs anywhere: when a database record needs to be
signed, I will generate the key pairs on the fly and create the
signature to be stored in a different table. Now, if I need to verify
data integrity, I will generate the signature from the original records
and compare it with the one created in the first place. Since this will
certainly happen in different times and database transactions I need a
way to get always the same key pair to sign/verify data.
I was thinking about using the default DSA parameters p,q,g and seeding
the SecureRandom with the same number: this should give always the same
key pairs.
The question is: are there security weaknesses in this model? I mean,
the whole security of this procedure relies on the key pairs which in
turn depend on p,q,g and the seed of SecureRandom: p,q and g are public.
The seed is the only hidden informatin and it will be kept in the java
class. How easy is to reverse-engineer a java class to read a single
integer number?
Thanks a lot in advance for your help
Sergio
Roedy Green - 06 Nov 2003 18:14 GMT
>Am I missing something or the signature lenght is not constant or
>there's some byte padding involved?
Digital signatures treat your message as a giant binary number. It can
help to prepend a positive byte on the front you discard later. This
ensures when your message is treated as a BigInteger, lead 0s will not
be dropped and you won't get into strange troubles with the sign.
I don't recall reading that digests guarantee any particular size,
just that they use X bits internally to generate.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.