[Twisted-Python] Regarding the SHA 512 support in twisted.

Adi Roiban adi at roiban.ro
Mon Mar 27 04:36:47 MDT 2017


Hi Jarib,

Thanks for the details.

On 27 March 2017 at 10:33, jabir Mohammed (jamohamm) <jamohamm at cisco.com> wrote:
> Hi Team,
>
> Wanted to bring one code changes which is really required from twisted side
> otherwise it is not behaving  as per RFC (rfc4253 Section 7.2), twisted is
> failing when we negotiate any kex algorithm based on SHA1 and we have MAC as
> hmac-sha2-512. The reason for the failure was the below code
>
> hashProcessor = _kex.getHashProcessor(self.kexAlg)
>         k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID)
>         k1 = k1.digest()
>         k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest()
> return k1 + k2
>
> For SHA512 we need 64 byte key and if the Kex is based on SHA1 then it will
> only generate 40 byte key and that induce a failure. So we need to modify
> the code as below to make it generic and make it comply with RFC (rfc4253
> Section 7.2). So that twisted can work irrespective of what kex is been
> used. Actual code should plot in is like below
>
> hashProcessor = _kex.getHashProcessor(self.kexAlg)
>         k1 = hashProcessor(sharedSecret + exchangeHash + c + self.sessionID)
>         k1 = k1.digest()
>         k2 = hashProcessor(sharedSecret + exchangeHash + k1).digest()
> k3 = hashProcessor(sharedSecret + exchangeHash + k1 + k2).digest()
> k4 = hashProcessor(sharedSecret + exchangeHash + k1 + k2 + k3).digest()
> return k1 + k2 + k3 + k4
>
> Can somebody help me to plot this fix so that twisted will work fine with
> all the other servers out there and even make it comply to the RFC. Thanks
> in advance and this will be my first findings on twisted code ;). Please let
> me know in case of any doubt on the same. Code changes should be plotted in
> to  the routine _getKey,  file name is src/twisted/conch/ssh/transport.py .
> Please help me with this commit team.

Happy to help.

Here should be the documentation for contributing  (hopefully is up to date)

http://twistedmatrix.com/trac/wiki/TwistedDevelopment

The first thing is to fork twisted/twisted, apply the change on the
branch and then create a PR.

By creating the PR, you will trigger some of the automated tests and
you can get a quick feedback.
.. for example to see if your changes are not introducing any regressions.

In an ideal world before making the changes and creating a simple
example so that we can manually check the changes you start by
updating the existing automated test to make sure that we don't
introduce regressions in the feature (as a non exhaustive list of
reasons)

You can use this file
https://github.com/twisted/twisted/blob/trunk/docs/conch/examples/sshsimpleserver.py
as the foundation for a simple example.
In the PR you can provide the client-side command use for the manual test

Looking forward for you PR.
I can help with the review and/or writing the automated tests.

You can also find me on #twisted-dev

Thanks,
Adi

> From: Alex Gaynor <alex.gaynor at gmail.com>
> Date: Wednesday, 1 March 2017 9:26 am
> To: jabir mohammed <jamohamm at cisco.com>
> Cc: Itamar Turner-Trauring <itamar at itamarst.org>,
> "security at twistedmatrix.com" <security at twistedmatrix.com>
> Subject: Re: Regarding the SHA 512 support in twisted.
>
> This doesn't appear to be a security issue. You can file an issue on the
> public tracker.
>
> Alex
>
> On Tue, Feb 28, 2017 at 10:54 PM, jabir Mohammed (jamohamm)
> <jamohamm at cisco.com> wrote:
>>
>>
>> Thanks Alex for the response. In our server we added support of
>> HMAC-SHA-512 and HMAC-SHA-256 support for MAC. When we try to negotiate this
>> hmac with most of the other client like Paramiko, OpenSSH and other flavours
>> of SSH its working fine. But we are seeing a problem with twisted client
>> that too only with HMAC-SHA-512. We have a limitation from our side to debug
>> this since we don’t know what is happening from the client side. We have
>> taken our derived key for the HMAC and as well as the input to derive the
>> MAC using online tools and it matches with whatever we have generated but
>> whatever is been sent across the other Twisted side differs and we are
>> closing the session. This is been tagged critical since most of the
>> customers are migrating to Twisted and will be a deployment blocker for us.
>>
>> What we suspect is the key or the algorithm itself. Please see the snippet
>> below
>>
>> This is our inmac Key
>> ----------------------------
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check:
>> inmac.key
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - a5 cb a5 bb 4c
>> 34 a7 bf-95 e9 00 23 1e 09 17 0c   ....L4.....#....
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 1c e1 3f d9 a7
>> 42 d9 87-54 23 64 16 e5 e2 c3 76   ..?..B..T#d....v
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - 2a bc 53 c6 85
>> 78 81 eb-e4 3e fb f7 cc a3 1f 6e   *.S..x...>.....n
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0030 - d9 a5 0e 73 d0
>> 44 79 a9-d3 19 32 3b 26 92 bb 70   ...s.Dy...2;&..p
>>
>> This is our input data to the hmac-sha-512
>> -----------------------------------------------------
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check:
>> input.data to HMAC API
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 00 00 00 03 00
>> 00 00 1c-0a 05 00 00 00 0c 73 73   ..............ss
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0010 - 68 2d 75 73 65
>> 72 61 75-74 68 64 de 66 fb ab 31   h-userauthd.f..1
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0020 - ba 7e 56 e5
>> .~V.
>>
>> The digest which is been sent from the twisted client side(Red)
>> -----------------------------------------------------------------------
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: ssh_integrity_check:
>> digest
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.895 : SSHD_[65795]: 0000 - 95 f7 99 27 48
>> 28 35 da-62 92 0e 51 0f af 62 b1   ...'H(5.b..Q..b.
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 93 d1 4d 46 5f
>> d9 21 7a-b9 fb 86 b6 6e 00 a3 aa   ..MF_.!z....n...
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 84 a9 58 60 5e
>> 1c 86 98-b4 1f 00 40 d5 72 aa cf   ..X`^...... at .r..
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 4b 1d 05 2d a4
>> 68 96 9c-7b c7 9d 83 1d c2 1d 5b   K..-.h..{……[
>>
>> The digest which got created from our side using the same key and input
>> data mentioned above(Green)
>> ———————————————————————————————————————————————————————————————
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0000 - 36 36 5c 6e 2d
>> be f1 d8-ae 4f 5a 72 30 2d 25 c0   66\n-....OZr0-%.
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0010 - 0e e8 d6 96 6e
>> 10 38 af-65 15 51 ff a7 ca 7d b4   ....n.8.e.Q...}.
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0020 - 7c c8 15 b8 5a
>> 9b 5e c4-b5 ac 4c 51 7e de 77 41   |...Z.^...LQ~.wA
>> RP/0/RSP0/CPU0:Feb 23 18:12:43.896 : SSHD_[65795]: 0030 - 32 63 61 5e f5
>> 1a 31 d1-f7 89 d0 0b 11 3c 48 f6   2ca^..1......<H.
>>
>> If you see the details this is the useauth first packet and we are not
>> able to proceed because of the failure. We used online tool to do this
>> calculation and we are getting the same output as what we generated so the
>> one marked as red is creating problem.So the root cause could be either the
>> key which is been derived or the algorithm so to debug that we need to
>> enable details logging from client side. We can share the details with
>> respective engineer and show what we are facing. Please help.
>>
>> Online tool which we used to check our algorithm is: which result in same
>> MAC marked as green.
>>
>> https://www.liavaag.org/English/SHA-Generator/HMAC/
>>
>>
>> Thanks,
>>
>> Jabir
>>
>>      \|/
>>
>>     -------
>>
>>    (  o o  )
>>
>> oooO---O---Oooonull
>>
>>
>> From: Alex Gaynor <alex.gaynor at gmail.com>
>> Date: Wednesday, 1 March 2017 6:39 am
>> To: Itamar Turner-Trauring <itamar at itamarst.org>
>> Cc: jabir mohammed <jamohamm at cisco.com>, "security at twistedmatrix.com"
>> <security at twistedmatrix.com>
>> Subject: Re: FW: Regarding the SHA 512 support in twisted.
>>
>> Hi,
>>
>> I think I'm missing some context here, what part of twisted are you trying
>> to use SHA-512 for a MAC with? It sounds like Conch? Can you show how I
>> could reproduce the problem?
>>
>> Alex
>>
>> On Tue, Feb 28, 2017 at 8:06 PM, Itamar Turner-Trauring
>> <itamar at itamarst.org> wrote:
>>>
>>> Hi,
>>>
>>> Forwarding on to security contact to see if they think it's a security
>>> problem; otherwise you can probably just file a normal ticket.
>>>
>>>
>>> On Tue, Feb 28, 2017, at 05:01 AM, jabir Mohammed (jamohamm) wrote:
>>>
>>> Hi Team,
>>>
>>>
>>> Wanted to cross check on SHA 512 algorithm as MAC while using twisted.
>>> Few of our customers started using Twisted and even we are trying to
>>> incorporate some scripts via twisted client. But what we have noticed is
>>> that when we negotiate SHA 512 MAC with twisted we always get a failure and
>>> other MAC algorithms are working fine with twisted. So wanted to cross check
>>> do we have any bug or any issue with SHA 512 and twisted and how we can
>>> debug this from twisted side.
>>>
>>> We checked the same with other OpenSSH client and even paramiko things
>>> work perfectly fine so wanted to debug further from the twisted side. We
>>> checked with the same derived key and the output whatever we got from SHA
>>> 512 is what we are getting from the online tool so we suspect something to
>>> do with the key or hash algorithm from the other side.
>>>
>>> We used the twisted 16.6.0 version for testing, thanks in advance for
>>> looking in to this email.
>>>



-- 
Adi Roiban




More information about the Twisted-Python mailing list