MIME-Version: 1.0
References: <CAEQQxWzdBy9JOC7+oQTBJ35Gov1CDk17fy+XH=jha8MuT9fy9Q@mail.gmail.com>
 <49999069-238D-4FBE-8F38-3762788A67C1@holtmann.org> <CAEQQxWxAvZBX8simb7gNu6ob_0gGXzTEQuOybiP5MTV8dq5sEg@mail.gmail.com>
In-Reply-To: <CAEQQxWxAvZBX8simb7gNu6ob_0gGXzTEQuOybiP5MTV8dq5sEg@mail.gmail.com>
From:   Andrey Batyiev <batyiev@gmail.com>
Date:   Tue, 8 Jan 2019 00:37:57 +0200
Message-ID: <CAEQQxWxpi7FR=RDT1cLMDBUUGzHSfSrgngHL7dCK5V1eJOOu3Q@mail.gmail.com>
Subject: Re: Bluetooth ECDH selftest failed (endianness issue?)
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     linux-bluetooth@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hello Marcel,

> On Sat, Dec 29, 2018 at 9:35 AM Marcel Holtmann <marcel@holtmann.org> wrote:
> I think that our ECDH code was endian safe, but then it got changed at some point to use standard crypto and maybe something went wrong there. Can just provide the btmon -w trace.log for the SMP pairing so that I can have a look at the binary trace.

I found out that if I change "swap_digits" method in
"net/bluetooth/ecdh_helper.c" to

static inline void swap_digits(u64 *in, u64 *out, unsigned int ndigits)
{
int i;

for (i = 0; i < ndigits; i++)
        out[i] = in[ndigits - 1 - i];
}

then BLE pairing on big-endian become operational. I'm not sure what
proper fix should be: is it a problem with crypto API usage or a
problem with crypto itself?

Thanks,
   Andrey