[OTR-dev] [OTR-users] otr dh key encryption

Ileana ileana at fairieunderground.info
Tue Feb 19 17:42:45 EST 2013


On Tue, 19 Feb 2013 22:05:13 +0000
Michael Rogers <michael at briarproject.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 19/02/13 18:13, Ileana wrote:
> >> Neither torchat nor OTR use 256 bit AES, they both use 128 bit
> >> AES.
> > 
> > OK...this part I am pretty sure is a mistake.  Tor purports to use 
> > AES-256 for all connections, including hidden services...I relooked
> > at the OTR code and see the that 16 bytes * 8 bits is indeed 128.
> 
> According to the spec, Tor uses 128-bit AES.
> 
> https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt
> 
> "For a stream cipher, we use 128-bit AES in counter mode, with an IV
> of all 0 bytes."

from tor src/common/crypto.h:  
/** Length of the output of our message digest. */
#define DIGEST_LEN 20
/** Length of the output of our second (improved) message digests.
(For now
 * this is just sha256, but it could be any other 256-bit digest.) */
#define DIGEST256_LEN 32
/** Length of our symmetric cipher's keys. */
#define CIPHER_KEY_LEN 16
/** Length of our symmetric cipher's IV. */
#define CIPHER_IV_LEN 16
/** Length of our public keys. */
#define PK_BYTES (1024/8)
/** Length of our DH keys. */
#define DH_BYTES (1024/8)

src/common/crypto.c
    log_engine("RSA", ENGINE_get_default_RSA());
      log_engine("DH", ENGINE_get_default_DH());
      log_engine("RAND", ENGINE_get_default_RAND());
      log_engine("SHA1", ENGINE_get_digest_engine(NID_sha1));
      log_engine("3DES", ENGINE_get_cipher_engine(NID_des_ede3_ecb));
      log_engine("AES", ENGINE_get_cipher_engine(NID_aes_128_ecb));
/** Number of bits to use when choosing the x or y value in a
Diffie-Hellman
 * handshake.  Since we exponentiate by this value, choosing a smaller
one
 * lets our handhake go faster.
 */
#define DH_PRIVATE_KEY_BITS 320


So you appear to be right again.  Have to watch out for listening to
"experts" in forum, etc.  It is important to note that tor is currently
upgrading to ec with 256 bit lengths, for version 2.4.

from tor crypto_curve25519.h  (in the new git repo):

/** Length of a curve25519 public key when encoded. */
#define CURVE25519_PUBKEY_LEN 32
/** Length of a curve25519 secret key when encoded. */
#define CURVE25519_SECKEY_LEN 32
/** Length of the result of a curve25519 handshake. */
#define CURVE25519_OUTPUT_LEN 32

.....

/** A paired public and private key for curve25519. **/
typedef struct curve25519_keypair_t {
  curve25519_public_key_t pubkey;
  curve25519_secret_key_t seckey;
} curve25519_keypair_t;




> 
> Another potential concern is that the hostname of a hidden service is
> based on the first 80 bits of the hash of the service's public key, so
> a collision can be generated after an expected 2^80 attempts.
> 
> https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt
> (see section 1.5)
> 
> Cheers,
> Michael




More information about the OTR-dev mailing list