The multiplication and subtraction circuits were found by djb using GNU
Superoptimizer, and the addition circuit is derived from the subtraction
one by hand. They depend on a different representation: -1 is now (1, 1)
rather than (1, 0), and the latter becomes undefined.
The following Python program checks that the circuits work:
values = [0, 1, -1]
def toBits(v):
if v == 0:
return 0, 0
elif v == 1:
return 0, 1
elif v == -1:
return 1, 1
else:
raise ValueError(v)
def mul((s1, a1), (s2, a2)):
return ((s1 ^ s2) & a1 & a2, a1 & a2)
def add((s1, a1), (s2, a2)):
t = s1 ^ a2
return (t & (s2 ^ a1), (a1 ^ a2) | (t ^ s2))
def sub((s1, a1), (s2, a2)):
t = a1 ^ a2
return ((s1 ^ a2) & (t ^ s2), t | (s1 ^ s2))
def fromBits((s, a)):
if s == 0 and a == 0:
return 0
if s == 0 and a == 1:
return 1
if s == 1 and a == 1:
return -1
else:
raise ValueError((s, a))
def wrap(v):
if v == 2:
return -1
elif v == -2:
return 1
else:
return v
for v1 in values:
for v2 in values:
print v1, v2
result = fromBits(mul(toBits(v1), toBits(v2)))
if result != v1 * v2:
raise ValueError((v1, v2, result))
result = fromBits(add(toBits(v1), toBits(v2)))
if result != wrap(v1 + v2):
raise ValueError((v1, v2, result))
result = fromBits(sub(toBits(v1), toBits(v2)))
if result != wrap(v1 - v2):
raise ValueError((v1, v2, result))
Change-Id: Ie1a4ca5a82c2651057efc62330eca6fdd9878122
Reviewed-on: https://boringssl-review.googlesource.com/c/34344
Reviewed-by: David Benjamin <davidben@google.com>
The last instruction did not unwind correctly. Also add .type and .size
annotations so that errors show up properly.
Change-Id: Id18e12b4ed51bdabb90bd5ac66631fd989649eec
Reviewed-on: https://boringssl-review.googlesource.com/c/34190
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
In [1], section 5.1, an optimised re-encryption process is given. In the
code, this simplifies to not needing to rebuild the ciphertext at all.
Thanks to John Schanck for pointing this out.
[1] https://eprint.iacr.org/2018/1174.pdf
Change-Id: I807bd509e936b7e82a43e8656444431546e9bbdf
Reviewed-on: https://boringssl-review.googlesource.com/c/33705
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
At some point after GCC 7.3, but before 8.2, GCC enabled the SSE ABI by
default. However, if it isn't enabled, the vector intrinsics in HRSS
cannot be used. (See https://github.com/grpc/grpc/issues/17540.)
Note that the intrinsics used are SSE2, but that should be ok because
they are guarded by a run-time check. The compile-time check for __SSE__
just ensures that GCC will build the code at all. (SDE does not simulate
anything that doesn't have SSE2, however.)
Change-Id: If092a06a441ed9d38576ea30351b3b40693a3399
Reviewed-on: https://boringssl-review.googlesource.com/c/33744
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
It's excessively complex to worry about leaving these few bits for
extensions. If we need to change things, we can spin a new curve ID in
TLS. We don't need to support two versions during the transition because
a fallback to X25519 is still fine.
Change-Id: I0a4019d5693db0f0f3a5379909d99c2e2c762560
Reviewed-on: https://boringssl-review.googlesource.com/c/33704
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Seeing the following errors with GCC 6 on ARM:
crypto/hrss/hrss.c:212:12: error: function declaration isn't a prototype [-Werror=strict-prototypes]
static int vec_capable() { return CRYPTO_is_NEON_capable(); }
^~~~~~~~~~~
crypto/hrss/hrss.c: In function 'vec_capable':
crypto/hrss/hrss.c:212:12: error: old-style function definition [-Werror=old-style-definition]
Change-Id: Ice540e6d436b8ada1dbc494f1feca10efff11687
Reviewed-on: https://boringssl-review.googlesource.com/c/33624
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Since the underlying operation is deterministic the confirmation hash
isn't needed and SXY didn't use it in their proof.
Change-Id: I3a03c20ee79645cf94b10dbfe654c1b88d9aa416
Reviewed-on: https://boringssl-review.googlesource.com/c/33605
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Since we build Chrome with -mfpu=neon anyway, this isn't currently
needed. Additionally, I had included poly3_invert_vec in the assembly
but hadn't gotten around to wiring it up yet. That assembly referenced a
couple of functions in the C code that had been renamed. Surprisingly,
the NDK linker didn't have a problem with the undefined symbols since it
could statically find them to be unreachable.
But that isn't true everywhere. Some builds did fail because of the
undefined symbols although we're not sure what's different about them.
(Different NDK version perhaps?)
Change-Id: Ibac4724d24df05d6f6007499e1cd884e59889101
Reviewed-on: https://boringssl-review.googlesource.com/c/33604
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Even if the vector code isn't used in hrss.c, it might call external
assembly that still requires alignment.
Change-Id: I11ceb88f96deec6b20883872030ca090506ca150
Reviewed-on: https://boringssl-review.googlesource.com/c/33584
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This change includes support for a variant of [HRSS], a post-quantum KEM
based on NTRU. It includes changes suggested in [SXY]. This is not yet
ready for any deployment: some breaking changes, like removing the
confirmation hash, are still planned.
(CLA for HRSS's assembly code noted in b/119426559.)
[HRSS] https://eprint.iacr.org/2017/667.pdf
[SXY] https://eprint.iacr.org/2017/1005.pdf
Change-Id: I85d813733b066d5c578484bdd248de3f764194db
Reviewed-on: https://boringssl-review.googlesource.com/c/33105
Reviewed-by: David Benjamin <davidben@google.com>
