[OTR-dev] OTR-dev Digest, Vol 16, Issue 2

interrupt80h at gmail.com interrupt80h at gmail.com
Sat Feb 13 14:19:07 EST 2010


We're not just interested in securing the communications, but also using it for identity verification and message signing. That said, I couldn't find documentation anywhere for the functions otrl_privkey_sign() and otrl_privkey_verify() and we've had some difficulty getting them to work properly. Are there any examples of how to properly use them, in particular creating the pubkey object to pass to verify?

Does this look at all correct:

SV* crypt_otr_get_pubkey_str( CryptOTRUserState in_state, char *account, char *proto, int maxsize ) {
  OtrlPrivKey *privkey = crypt_otr_get_privkey( in_state, account, proto, maxsize );
  SV *privkey_sv = newSVpvn(privkey->pubkey_data, privkey->pubkey_datalen);
  return privkey_sv;
}

unsigned int crypt_otr_verify( unsigned char *msghash, unsigned char *sig, unsigned char *pubkey_data,
                               size_t pubkey_length, unsigned short pubkey_type) {

  // create s-expression object representing the public key
  gcry_sexp_t pubkey;

  gcry_sexp_new(&pubkey, pubkey_data, pubkey_length, 1);

  gcry_error_t err = otrl_privkey_verify( sig, strlen(sig), pubkey_type, pubkey, msghash, strlen(msghash) );

  gcry_sexp_release(pubkey);

  return err == 0;
}



On Feb 13, 2010, at 6:35 AM, Ian Goldberg wrote:

> On Fri, Feb 12, 2010 at 10:24:10PM -0700, Peter Saint-Andre wrote:
>> On 2/12/10 9:31 PM, Patrick Tierney wrote:
>> 
>>> We weren't targeting it at IM in particular. Considering that Perl has
>>> modules to handle all sorts of data, the plugin could expand OTR to
>>> secure many new types of communication (file exchange, voice, video).
>> 
>> Sounds intriguing. I'd be curious to hear how you propose to do that. My
>> understanding of OTR has always been that it is designed to exchange
>> basic text messages and perhaps XHTML-formatted versions of those
>> messages, but not the kind of extended data that is necessary to
>> negotiate multimedia sessions and not the data itself (which might be
>> transferred via direct TCP streams, UDP associations, media relays, and
>> the like).
> 
> There's nothing preventing the underlying OTR protocol from being used
> to protect arbitrary binary data, so long as the network model
> (unreliable, but in-order, delivery) is preserved.  The protocol spec
> only says how to use it for IM messages, but someone could easily write
> a spec for OTR-protected VoIP, for example.  [You'd probably want to
> rekey a little less often, perhaps.]
> 
>   - Ian
> _______________________________________________
> OTR-dev mailing list
> OTR-dev at lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-dev




More information about the OTR-dev mailing list