linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Emil Lenngren <emil.lenngren@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Andrey Batyiev <batyiev@gmail.com>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Bluez mailing list <linux-bluetooth@vger.kernel.org>
Subject: Re: Bluetooth ECDH selftest failed (endianness issue?)
Date: Fri, 18 Jan 2019 08:51:10 -0500	[thread overview]
Message-ID: <CAO1O6sfFqcQvn2Sy_HOLAzuc9o-Wu0g_9oLH-OFOkCxfuA=Jtg@mail.gmail.com> (raw)
In-Reply-To: <82ABD3A9-290C-4291-A84D-C4C2DE62CD17@holtmann.org>

Hi,

Den fre 18 jan. 2019 kl 04:44 skrev Marcel Holtmann <marcel@holtmann.org>:
>
> Hi Andrey,
>
> >> 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?
>
> if the kernel ECC and ECDH crypto already swaps for us, then we don’t need to do it again. So all the swap_digits most likely can be removed from net/bluetooth/.
>
> Regards
>
> Marcel
>

The Bluetooth standard is a bit strange. It assumes the AES standard
is big endian (although it is really just defined on a byte level),
but since Bluetooth is little-endian everywhere, all AES 128-bit
values must be reversed when a standard AES library is used. In
particular, SMP reverses the AES values. So the swap_digits should be
kept.

/Emil

  reply	other threads:[~2019-01-18 13:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-27  3:21 Bluetooth ECDH selftest failed (endianness issue?) Andrey Batyiev
2018-12-29  7:35 ` Marcel Holtmann
2019-01-03 20:19   ` Andrey Batyiev
2019-01-07 22:37     ` Andrey Batyiev
2019-01-18  9:43       ` Marcel Holtmann
2019-01-18 13:51         ` Emil Lenngren [this message]
2019-01-21 14:53           ` Marcel Holtmann
2019-01-21 16:56             ` Emil Lenngren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO1O6sfFqcQvn2Sy_HOLAzuc9o-Wu0g_9oLH-OFOkCxfuA=Jtg@mail.gmail.com' \
    --to=emil.lenngren@gmail.com \
    --cc=batyiev@gmail.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).