[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:53:35 CEST 2009


George,

unfortunately BC cannot generate the required key pairs. Thus BC
implemented FIPS-186-3 with respect to the signature but not with
respect generate key pairs suitable for hash sizes greater than
160 bits. Thus the idea mentioned does not work out :-( .

Regards,
Werner

Werner Dittmann schrieb:
> 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
> 
> 


---------------------------------------------------------------------
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