hi folks,

i am trying to write an application that has two independent 
requirements that involve cryptography:
- encrypt/decrypt and sign/verify messages
- secure tcp sockets against eavesdropping and tampering
all peers and their keys are known, so i need no key distribution
infrastructure. for technical reasons all my messages are binary, so i
will not use any hex encoding or so below. i am trying to implement 
this using crypto++ (which is really awesome so far!), but i am unsure 
about some points, so i'd be glad if you guys could have a look and 
tell me if you spot anything obviously stupid, or some poor choices. 
my approach so far is:

- generate a signing key for each peer adn store it in the application's
  (secure) database:
  RSASSA_PKCS1v15_SHA_Signer privS(rng, 2048);
  i store the output from privS.DEREncode() directly. I also do not
  store the public key as it can be regenerated from the private key on
  loading
- similar, generate and handle an encryption pair, i use
  RSAES_OAEP_SHA_Decryptor
- i then sign the binary public encryption key and distribute the public
  signing key, the public encryption key and the signature on the
  signing key to my peers. i have a way to verify a public signing key
  belongs to the peer that claims so (a fingerprint->peer_id table).
- i generate fingerprints of the public keys (for identification) by
  SHA256ing the binary DEREncode() output
- to secure communication channels, i use DH (should i use DH2?) as 
  described on the wiki [0], but i do not negotiate g and p, but have
  them fixed in the application (to minimise protocol overhead). to
  guard against man in the middle attacks, each participant signs the
  agreed key and sends the signature with the first package. i would use
  the same signing key for this as for the rest above (for simplicity)

that's it. looks simple and sound to me, but with crypto it is really
easy (at least for me) to spot obvious mistakes...

thanks  robert

[0] http://www.cryptopp.com/wiki/Diffie-Hellman_Key_Exchange

-- 
Robert Lemmen                               http://www.semistable.com 

Attachment: signature.asc
Description: Digital signature

Reply via email to