[sip-comm-dev] GSoC 09 - OTR - First term results (DSA Signature sign/verify using BC/libgcrypt)

Werner Dittmann Werner.Dittmann at t-online.de
Thu Jul 16 17:40:13 CEST 2009


Hi George,

Geekius Caesar schrieb:
> Hello Werner,
> 
> Thank you for clearing things up. It was too hard to believe that a buggy
> DSA signature generation/verification algorithm existed in a so
> popular/essential library such as libgcrypt -shame on me for not taking a
> look in older specifications-. This seems to lead into an "interoperability
> hell", maybe signers should be further parametrized to support operation
> modes per FIPS, but that is out of the scope of this discussion and not our
> problem :)
> 
> As for OTR implementation discovery, OTR protocol does not define a way that
> allows that (OTR implementation discovery) during the Authenticated Key
> Exchange (this is the part where we need it).
> 
> A non-standard *extension *to the OTR protocol that would allow OTR
> implementation discovery would be to define one more whitespace tag + a
> unique query message that only otr4j would understand it's special meaning
> but still remain compatible with standard OTR whitespace tags and query
> messages, but I want to finish with the library and start building the SC
> UI, so I would like to stick with the "buggy" signature for now if that's OK
> with you.

absolutely ok. Just go on with this and complete alle necessary functions
of the lib and the integration into SC.

I have an idea how to solve the signature issue, just need to do some
tests how to generate a DSA keypair that has a key strength of
L=2048, N=256. If N=256 then the bit length of q is also 256 and this
is then the same length as the SAH256HMAC and its not truncated. For
verification we probably need to stay with the "double-verify" method.

Regards,
Werner

> 
> kind regards,
> George
> 
> On Wed, Jul 15, 2009 at 4:39 PM, Werner Dittmann <
> Werner.Dittmann at t-online.de> wrote:
> 
>> George, Emil,
>>
>> the BC DSA signature algorithm implements the latest standard according
>> to FIP-186-3. This standard is _very_ new (approved in 2009) and only this
>> standard allows hashes other than SHA-1.
>>
>> Thus the implementation in libgcrypt is not buggy but adheres to
>> FIPS-186-1,
>> 186-2. As a matter of fact, it's the OTR implementation that "misused" DSA
>> because it uses an SHA256 HMAC as input even for DSA implementations
>> according to FIPS-186-2 ;-).
>>
>> AFAIK OTR uses DSA domain parameters that generate a 1024bit p (L) and a
>> 160bit q (N) to sign the output of a 256 HMAC. This is not according to
>> FIPS-186-3 that states:
>>
>> <quote>
>> It is recommended that the security strength of the (L, N) pair and the
>> security strength of the
>> hash function used for the generation of digital signatures be the same
>> unless an agreement has
>> been made between participating entities to use a stronger hash function.
>> When the length of the
>> output of the hash function is greater than N (i.e., the bit length of q),
>> then the leftmost N bits of
>> the hash function output block shall be used in any calculation using the
>> hash function output
>> during the generation or verification of a digital signature. A hash
>> function that provides a lower
>> security strength than the (L, N) pair ordinarily should not be used, since
>> this would reduce the
>> security strength of the digital signature process to a level no greater
>> than that provided by the
>> hash function.
>> </quote>
>>
>>
>> As for SC: currently the libotr uses this and I would recomend to be "bug"
>> compliant and generate "buggy" signature when otr4j cannot detect which
>> type to
>> use. Because otr4j knows about this problem it can deal with this during
>> verification (receiver makes it right). Using this way interop with libotr
>> works.
>>
>> BTW, is there any way during the previous messages to detect which otr
>> implementation is used by the other party? ZRTP for example provides this
>> information during the Hello handshake (protocol version number of
>> implementation
>> info of the ZRTP protocol implementation). If this is possible then we
>> could insert a SC identification and select the right way to do DSA.
>>
>> Regards,
>> Werner
>>
>>
<SNIP --- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net





More information about the dev mailing list