profile
viewpoint

agl/critbit 270

Critbit trees in C

agl/curve25519-donna 245

Implementations of a fast Elliptic-curve Diffie-Hellman primitive

agl/ed25519 167

ed25519 for Go

agl/jbig2enc 143

JBIG2 Encoder

agl/ctgrind 129

Checking that functions are constant time with Valgrind

agl/crlset-tools 108

Tools for dealing with Chrome's CRLSets

agl/dnssec-tls-tools 32

DNSSEC/TLS tools

agl/dnscurve 23

Tools for DNS curve implementation

agl/certificatetransparency 18

Certificate Transparency stuff

Pull request review commentw3c/webauthn

Add “enterprise” attestation type.

 during credential generation.     ::  This value indicates that the [=[RP]=] wants to receive the [=attestation statement=] as generated by the         [=authenticator=]. +    :   <dfn>enterprise</dfn>+    ::  This value indicates that the [=[RP]=] wants to receive an [=attestation statement=] that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. User agents MUST NOT provide such an attestation unless user agent or authenticator configuration permits it for the requested [=RP ID=]. If not permitted, the user agent SHOULD treat this value the same as `direct`.

Have changed to a MUST because the SHOULD introduces unneeded ambiguity. I'm not actually sure whether fall back to “direct” or immediate rejection is actually the right behaviour. However, if we pick the former then we should firmly pick it.

agl

comment created time in 4 days

Pull request review commentw3c/webauthn

Add “enterprise” attestation type.

 during credential generation.     ::  This value indicates that the [=[RP]=] wants to receive the [=attestation statement=] as generated by the         [=authenticator=]. +    :   <dfn>enterprise</dfn>+    ::  This value indicates that the [=[RP]=] wants to receive an [=attestation statement=] that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. User agents MUST NOT provide such an attestation unless user agent or authenticator configuration permits it for the requested [=RP ID=]. If not permitted, the user agent SHOULD treat this value the same as `direct`.

Maybe, but I don't think so? For example, what would a call with enterprise + none-attestation mean? I.e. I don't think the cross-product is meaning in several cases thus I'm casting this as an alternative.

agl

comment created time in 4 days

Pull request review commentw3c/webauthn

Add “enterprise” attestation type.

 a numbered step. If outdented, it (today) is rendered either as a bullet in the                          :   "direct"                         ::  Convey the [=authenticator=]'s [=AAGUID=] and [=attestation statement=], unaltered, to the [=[RP]=].++                        :   "enterprise"+                        ::  If user agent or authenticator configuration permits it for the requested [=RP ID=], signal to the authenticator that enterprise attestation is permitted and convey the resulting [=AAGUID=] and [=attestation statement=], unaltered, to the [=[RP]=]. If not permitted, act the same as if the value were "direct".

Good point, thanks. I've (maybe) fixed this change to signal at the correct time.

agl

comment created time in 4 days

Pull request review commentw3c/webauthn

Add “enterprise” attestation type.

 a numbered step. If outdented, it (today) is rendered either as a bullet in the                          :   "direct"

Done.

agl

comment created time in 4 days

push eventagl/webauthn

Adam Langley

commit sha cb723d9bdf9da86e26e0e4087b9fbbfc954075e6

Signal attestation at the correct time.

view details

push time in 4 days

push eventgoogle/boringssl

Shelley Vohr

commit sha 6432bb46ab44731567ec923e6c8fc182f13d0070

Add ECDSA_SIG_get0_r and ECDSA_SIG_get0_s. OpenSSL 1.1.1 added some more convenient versions of ECDSA_SIG_get0. Node.js uses them. Change-Id: I425e8a0c2e43c34130f30d902090b839f1a67186 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40044 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha f1d8e7640abf2923975d0c85f66ae43991f024bf

update master-with-bazel from master branch

view details

push time in 5 days

push eventgoogle/boringssl

Shelley Vohr

commit sha 6432bb46ab44731567ec923e6c8fc182f13d0070

Add ECDSA_SIG_get0_r and ECDSA_SIG_get0_s. OpenSSL 1.1.1 added some more convenient versions of ECDSA_SIG_get0. Node.js uses them. Change-Id: I425e8a0c2e43c34130f30d902090b839f1a67186 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40044 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 5 days

push eventgoogle/boringssl

Adam Langley

commit sha 472d91c39c86974d14551871fea4c194f3c3bba3

Fix a couple of comment typos. Thanks to Tobias Thierer for pointing these out. (No semantic change.) Change-Id: Ia191da6353a11b090201adf813e2ca271acaff2e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40104 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 952ffb6ede07e73512534d5570733a75918debcf

update master-with-bazel from master branch

view details

push time in 5 days

push eventgoogle/boringssl

Adam Langley

commit sha 472d91c39c86974d14551871fea4c194f3c3bba3

Fix a couple of comment typos. Thanks to Tobias Thierer for pointing these out. (No semantic change.) Change-Id: Ia191da6353a11b090201adf813e2ca271acaff2e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40104 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 5 days

issue commentw3c/webappsec-subresource-integrity

SHA-3/Keccak

Adding primitives costs implementation time, validation & compliance time, and code size. It also has non-linear costs in terms of supporting and testing all the various combinations that it introduces across various protocols.

Since we already have secure hash functions in the form of SHA-256 and SHA-512, we've no plans to support SHA-3 generally.

smarts

comment created time in 5 days

push eventgoogle/boringssl

David Benjamin

commit sha a12a2497ffc95a4f75e50d6d7e861e7bee7b8a5e

Const-correct various X509_NAME APIs. Half of them were marked const and half weren't. Change-Id: Ia9135f743b06f07aafac8655ded84d01e59cf481 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39764 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha ff492b80513575b5aef26bcd59d41f2a090dd0b1

update master-with-bazel from master branch

view details

push time in 6 days

push eventgoogle/boringssl

David Benjamin

commit sha a12a2497ffc95a4f75e50d6d7e861e7bee7b8a5e

Const-correct various X509_NAME APIs. Half of them were marked const and half weren't. Change-Id: Ia9135f743b06f07aafac8655ded84d01e59cf481 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39764 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 6 days

push eventgoogle/boringssl

Adam Langley

commit sha 7940ed1f304e82eee22fb072c05f204187f87cec

Ignore old -enable-ed25519 flag. Change 1766935f76 removed this flag but it's useful if bssl_shim ignores it to reduce noise in cross-version testing. This can be dropped in three months once the old versions have aged out. Change-Id: I73f2bebeb5e8c178253fbb6915026e06b6ad58bc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40084 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 708e1490cd985f999ee1e08430a10e11ef309832

update master-with-bazel from master branch

view details

push time in 8 days

push eventgoogle/boringssl

Adam Langley

commit sha 7940ed1f304e82eee22fb072c05f204187f87cec

Ignore old -enable-ed25519 flag. Change 1766935f76 removed this flag but it's useful if bssl_shim ignores it to reduce noise in cross-version testing. This can be dropped in three months once the old versions have aged out. Change-Id: I73f2bebeb5e8c178253fbb6915026e06b6ad58bc Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40084 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 8 days

push eventgoogle/boringssl

Adam Langley

commit sha f1efbc8f8be9ce2918eaf46c48f294cb214023b9

Provide __NR_getrandom fillins in urandom test too. The urandom test added in 3e502c84f04 assumed that __NR_getrandom was defined by the system's headers, but urandom.c doesn't. This change pulls the fills for that system call into a common header that's used by both. Change-Id: I71c3b9bfa69c34b320e724a4c977cd63163cbdec Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40067 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha e4622895a155927ce36899e9ba1ed795853e5d75

update master-with-bazel from master branch

view details

push time in 9 days

push eventgoogle/boringssl

Adam Langley

commit sha f1efbc8f8be9ce2918eaf46c48f294cb214023b9

Provide __NR_getrandom fillins in urandom test too. The urandom test added in 3e502c84f04 assumed that __NR_getrandom was defined by the system's headers, but urandom.c doesn't. This change pulls the fills for that system call into a common header that's used by both. Change-Id: I71c3b9bfa69c34b320e724a4c977cd63163cbdec Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40067 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha aadb46369ae0b33d8a642617ad938b6a6c5f54e1

Skip RSATest.DISABLED_BlindingCacheConcurrency in SDE. The SDE bot has started developing flakes with that many threads. (Unclear if it is due to SDE or running too many copies of the test in parallel.) Change-Id: I0081b6d75882b946bdccee5405dc688d0035d565 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40066 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha b865e927dcf3dcd2d8bc1b76efc06cf4c07b62f7

update master-with-bazel from master branch

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha aadb46369ae0b33d8a642617ad938b6a6c5f54e1

Skip RSATest.DISABLED_BlindingCacheConcurrency in SDE. The SDE bot has started developing flakes with that many threads. (Unclear if it is due to SDE or running too many copies of the test in parallel.) Change-Id: I0081b6d75882b946bdccee5405dc688d0035d565 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40066 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 754d4c99c8fd9dec3e251799d57612ebf9136ac4

Fix client handling of 0-RTT rejects with cipher mismatch. Servers can only accept 0-RTT if the ciphers match. If they reject 0-RTT, however, they may change the cipher suite and even the PRF hash. This is tricky, however, because the 0-RTT accept or reject signal comes in EncryptedExtensions, which is *after* the new cipher suite is installed. (Although a client could infer 0-RTT is rejected based on the cipher suite if it wanted.) While we correctly handled the PRF hash switch, we get the cipher suite mixed up due to dependency on SSL_get_session and incorrectly decrypt EncryptedExtensions. Fix this and add some tests. Change-Id: Ia20f2ed665cf601d30a38f0c8d4786c4c111019f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40005 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha e770d426d92bb5415a17501b268d285545a6427e

update master-with-bazel from master branch

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 754d4c99c8fd9dec3e251799d57612ebf9136ac4

Fix client handling of 0-RTT rejects with cipher mismatch. Servers can only accept 0-RTT if the ciphers match. If they reject 0-RTT, however, they may change the cipher suite and even the PRF hash. This is tricky, however, because the 0-RTT accept or reject signal comes in EncryptedExtensions, which is *after* the new cipher suite is installed. (Although a client could infer 0-RTT is rejected based on the cipher suite if it wanted.) While we correctly handled the PRF hash switch, we get the cipher suite mixed up due to dependency on SSL_get_session and incorrectly decrypt EncryptedExtensions. Fix this and add some tests. Change-Id: Ia20f2ed665cf601d30a38f0c8d4786c4c111019f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40005 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 83ea777db54769c8bb95ddd62bf11c3946e6d3bf

runner: Tidy up 0-RTT support. earlyCipherSuite is a remnant of early exporters, which we've since removed. Also runner should perform the cipher suite matching check for 0-RTT. Change-Id: Ia6dc2ff6cf7072d94820e8755acd555037c557f1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40004 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 471134eb6567c59b269483e64fac536370d9dc3d

update master-with-bazel from master branch

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 83ea777db54769c8bb95ddd62bf11c3946e6d3bf

runner: Tidy up 0-RTT support. earlyCipherSuite is a remnant of early exporters, which we've since removed. Also runner should perform the cipher suite matching check for 0-RTT. Change-Id: Ia6dc2ff6cf7072d94820e8755acd555037c557f1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40004 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 0dc70e462c058356e7a3ccb97e74690aab44c23f

Add X509_getm_notBefore and X509_getm_notAfter. This functions were added in OpenSSL 1.1.0. Change-Id: I1ee78ba124534d6e3e47edf75c0b4fed51388a6e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40024 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 0dc70e462c058356e7a3ccb97e74690aab44c23f

Add X509_getm_notBefore and X509_getm_notAfter. This functions were added in OpenSSL 1.1.0. Change-Id: I1ee78ba124534d6e3e47edf75c0b4fed51388a6e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40024 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 4cb12310b7768f9ebc08922f93dd996c669d1c55

update master-with-bazel from master branch

view details

push time in 9 days

push eventgoogle/boringssl

David Benjamin

commit sha 0c30649ba676e73a4bbb449ee684ccf2d452f7f6

Clean up TLS 1.3 handback logic. There's no need to treat the 1-RTT and 0-RTT handback flows differently. This aligns the 1-RTT handback with the 0-RTT point. This consistently installs the decryption keys in the state machine after handback rather than while applying the handback. Update-Note: This changes the serialization format for TLS 1.3 split handshakes, which were only just added. Change-Id: I0e109cb8d9ecd3c8658dfa26059cbe0139f82eed Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39988 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Matt Braithwaite <mab@google.com>

view details

BoringSSL Robot

commit sha 33019e3ff5c2db9026d9b8cd49804034338f71af

update master-with-bazel from master branch

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha 0c30649ba676e73a4bbb449ee684ccf2d452f7f6

Clean up TLS 1.3 handback logic. There's no need to treat the 1-RTT and 0-RTT handback flows differently. This aligns the 1-RTT handback with the 0-RTT point. This consistently installs the decryption keys in the state machine after handback rather than while applying the handback. Update-Note: This changes the serialization format for TLS 1.3 split handshakes, which were only just added. Change-Id: I0e109cb8d9ecd3c8658dfa26059cbe0139f82eed Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39988 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Matt Braithwaite <mab@google.com>

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha f9cc26f9c1c07668e29be71e08324f68d50d0942

Require handshake flights end at record boundaries. The TLS handshake runs over a sequence of messages, serialized onto a stream, which is then packetized into records, with no correlation to message boundaries. TLS messages may span records, so a TLS implementation will buffer up excess data in a record for the next message. If not checked, that next message may a round-trip or even a key change later. Carrying data across a key change has security consequences, so we reject any excess data across key changes (see ChangeCipherSpec synchronization tests and (d)tls_set_read_state). However, we do not currently check it across network round trips that do not change keys. For instance, a TLS 1.2 client may pack part of ClientKeyExchange (the first byte, at least, is deterministic) into the ClientHello record, before even receiving ServerHello. Most TLS implementations will accept this. However, the handback logic does *not* serialize excess data in hs_buf. There shouldn't be any, but if the peer is doing strange things as above, that data will get silently dropped. The way TLS 1.3 0-RTT handback logic works (the key isn't installed until after handback), this data is even silently dropped though there is a key change. To keep all our behavior consistent, check for unprocessed handshake data at the end of each flight and reject it. Add a bunch of tests. Update-Note: If the peer packs data across handshake flights, or packs HelloRequest into the same record as Finished, this will now be an error. (The former is pathologically odd behavior. The latter is also rejected by Schannel and also odd.) Change-Id: I9412bbdea09ee7fdcfeb78d3456329505a190641 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39987 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 30a8541aa665ead8b07d24a3242ad85c29b2b28d

update master-with-bazel from master branch

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha f9cc26f9c1c07668e29be71e08324f68d50d0942

Require handshake flights end at record boundaries. The TLS handshake runs over a sequence of messages, serialized onto a stream, which is then packetized into records, with no correlation to message boundaries. TLS messages may span records, so a TLS implementation will buffer up excess data in a record for the next message. If not checked, that next message may a round-trip or even a key change later. Carrying data across a key change has security consequences, so we reject any excess data across key changes (see ChangeCipherSpec synchronization tests and (d)tls_set_read_state). However, we do not currently check it across network round trips that do not change keys. For instance, a TLS 1.2 client may pack part of ClientKeyExchange (the first byte, at least, is deterministic) into the ClientHello record, before even receiving ServerHello. Most TLS implementations will accept this. However, the handback logic does *not* serialize excess data in hs_buf. There shouldn't be any, but if the peer is doing strange things as above, that data will get silently dropped. The way TLS 1.3 0-RTT handback logic works (the key isn't installed until after handback), this data is even silently dropped though there is a key change. To keep all our behavior consistent, check for unprocessed handshake data at the end of each flight and reject it. Add a bunch of tests. Update-Note: If the peer packs data across handshake flights, or packs HelloRequest into the same record as Finished, this will now be an error. (The former is pathologically odd behavior. The latter is also rejected by Schannel and also odd.) Change-Id: I9412bbdea09ee7fdcfeb78d3456329505a190641 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39987 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 10 days

push eventgoogle/boringssl

David Benjamin

commit sha 21a879a78a60c8667468a9eba994c8365eaf92ea

Delete unreachable DTLS check. It is impossible for us to have an unconsumed ChangeCipherSpec message in dtls_has_unprocessed_handshake_data. dtls_has_unprocessed_handshake_data is only called in dtls1_set_read_state and, in DTLS 1.2 and earlier, we only ever switch the cipher state immediately after consuming ChangeCipherSpec. Remove this because later commits will check has_unprocessed_handshake_data in more places and we have a test (StrayChangeCipherSpec) which asserts we do tolerate arbitrarily early ChangeCipherSpecs messages. There may be something to be said for rejecting this (the peer would have to be doing something weird and sending ChangeCipherSpec in the wrong flight), but ChangeCipherSpec in DTLS is predictable and informationless, so this is probably not worth worrying about. Change-Id: I1bc2952c0ba5231a7f962b9f7ca4c63271ec079f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39986 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 2867c030e8294f6e55f43066213b57b9664b6e05

update master-with-bazel from master branch

view details

push time in 12 days

push eventgoogle/boringssl

David Benjamin

commit sha f6cc8ddf52ec22596658c2457a41a5c09e3f3b22

Rename ssl3_choose_cipher. We don't support SSL 3.0 anymore. It's also file-local, so it can be choose_cipher. Change-Id: Idab96496eda69c7fd906aa788ac26e8d30c317d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39984 Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 82a4b2234ece952a98c653cdcd207d1c02e92009

Rename TLS-specific functions to tls_foo from ssl3_foo. Some of the TLS-specific functions begin with ssl3_, otherwise with tls_. Align on tls_ since we don't implement SSL 3.0 anymore. (Plain ssl_ means common to TLS and DTLS, which is an odd backronym, but SSL_foo for the APIs are thoroughly stuck.) Change-Id: Ib7acffd21ee370bb9bed46789fb511d00fac24ca Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39985 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 1e14852a08504ad0e85a5afc718510b9ce80678c

update master-with-bazel from master branch

view details

push time in 12 days

push eventgoogle/boringssl

David Benjamin

commit sha 82a4b2234ece952a98c653cdcd207d1c02e92009

Rename TLS-specific functions to tls_foo from ssl3_foo. Some of the TLS-specific functions begin with ssl3_, otherwise with tls_. Align on tls_ since we don't implement SSL 3.0 anymore. (Plain ssl_ means common to TLS and DTLS, which is an odd backronym, but SSL_foo for the APIs are thoroughly stuck.) Change-Id: Ib7acffd21ee370bb9bed46789fb511d00fac24ca Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39985 Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 21a879a78a60c8667468a9eba994c8365eaf92ea

Delete unreachable DTLS check. It is impossible for us to have an unconsumed ChangeCipherSpec message in dtls_has_unprocessed_handshake_data. dtls_has_unprocessed_handshake_data is only called in dtls1_set_read_state and, in DTLS 1.2 and earlier, we only ever switch the cipher state immediately after consuming ChangeCipherSpec. Remove this because later commits will check has_unprocessed_handshake_data in more places and we have a test (StrayChangeCipherSpec) which asserts we do tolerate arbitrarily early ChangeCipherSpecs messages. There may be something to be said for rejecting this (the peer would have to be doing something weird and sending ChangeCipherSpec in the wrong flight), but ChangeCipherSpec in DTLS is predictable and informationless, so this is probably not worth worrying about. Change-Id: I1bc2952c0ba5231a7f962b9f7ca4c63271ec079f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39986 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 12 days

push eventgoogle/boringssl

David Benjamin

commit sha f6cc8ddf52ec22596658c2457a41a5c09e3f3b22

Rename ssl3_choose_cipher. We don't support SSL 3.0 anymore. It's also file-local, so it can be choose_cipher. Change-Id: Idab96496eda69c7fd906aa788ac26e8d30c317d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39984 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 12 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 8f299d5e03cb11b9f6f1b9dbc6f5b1c1033e4424

SSL_apply_handback: don't choke on trailing data. It may be useful for future extensibility. Change-Id: I415095140367a44a2c8dd636998721399232c400 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39964 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 33a383530d67dab9874834c22b30a6e3c7caef49

update master-with-bazel from master branch

view details

push time in 12 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 8f299d5e03cb11b9f6f1b9dbc6f5b1c1033e4424

SSL_apply_handback: don't choke on trailing data. It may be useful for future extensibility. Change-Id: I415095140367a44a2c8dd636998721399232c400 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39964 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

push time in 12 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 4f3e8212ea413d0bc271054a12ed581bc742e825

ssl_test: test early data with split handshakes. This helps to clarify where SSL_set_early_data_enabled() needs to be called: in the shim tests it was being set everywhere, which concealed the fact that the |enable_early_data| bit was not being set by SSL_apply_handback(). Change-Id: I35bfdc6dd43f4fa07ef79eb02e4624b59fcdda5e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39385 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 13 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 4f3e8212ea413d0bc271054a12ed581bc742e825

ssl_test: test early data with split handshakes. This helps to clarify where SSL_set_early_data_enabled() needs to be called: in the shim tests it was being set everywhere, which concealed the fact that the |enable_early_data| bit was not being set by SSL_apply_handback(). Change-Id: I35bfdc6dd43f4fa07ef79eb02e4624b59fcdda5e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39385 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 58ed698e5a15ba49baa661ed45d68e2e47fde83e

update master-with-bazel from master branch

view details

push time in 13 days

push eventgoogle/boringssl

Adam Langley

commit sha 2865bce1b2ede077074f36f29e81ba4696185b23

FIPS.md: document some recent Android changes. Change-Id: I48cc5fc6211a1a557cfeb1aad5688753bc7b5dfd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38124 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 5cf3298140ae4e4d219a0703c5280fa327c361fa

Fix the FIPS + fuzzing build. Recent changes to the PRNG seeding in FIPS mode broke the build when trying to build with both FIPS and fuzzing enabled. Change-Id: I069b4af1fdd4efaef96e3e3b3a1e0197faabe2e1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38184 Reviewed-by: Matt Braithwaite <mab@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 18d145e651b6c80ae562bcf41ff804aaad674595

Extract and test the deterministic part of Miller-Rabin. This way we test not only that we match expectations for primes and composites but that the core test correctly reports false witnesses. I made an initial attempt to gather some interesting test input, but probably one can do better. Change-Id: I7c29afb534bd6980ef42a893e86d86bd44af8349 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38164 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha fba30c389c1c23b00f5f60953d7ad0374f9cc105

Break early on composites in the primality test. |a| is usually much smaller than |w_bits|. We only need to loop up to |w_bits| and hide |a| when the value is possibly composite. If Miller-Rabin has not hit -1 by then, break early. This speeds up RSA keygen by a bit. Before: Did 248 RSA 2048 key-gen operations in 30041496us (8.3 ops/sec) min: 31690us, median: 109097us, max: 373911us Did 71 RSA 3072 key-gen operations in 30096719us (2.4 ops/sec) min: 108650us, median: 370844us, max: 1768070us Did 27 RSA 4096 key-gen operations in 32829007us (0.8 ops/sec) min: 205485us, median: 1107051us, max: 4035040us After: Did 340 RSA 2048 key-gen operations in 30026342us (11.3 ops/sec) min: 24681us, median: 77749us, max: 350477us Did 67 RSA 3072 key-gen operations in 30089075us (2.2 ops/sec) min: 75070us, median: 394220us, max: 1101562us Did 38 RSA 4096 key-gen operations in 30283788us (1.3 ops/sec) min: 284947us, median: 742688us, max: 1970468us Change-Id: If1b48e9306c3fe1be56c304143e206c3bdb3301d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38165 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 841a40a2769bb92e395906b547464546f886785c

Add some notes on RSA key generation performance. Change-Id: I8c0cadddcfc7d8b14adbc3ed3b75332859deea42 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38166 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 642664838ae91b943c6fd061f595253ac2ebe06c

Simplify bn_miller_rabin_iteration slightly. We don't need both mask variables. If we know we have a composite witness, we return immediately, so the only time we mask off instructions is when we know we have a nonwitness. Change-Id: I2b99f3114a79ce2dc1a37706835d2abfe93a716e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38167 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha f3bd757ee5e7ad409d2fdf7c3bb5fdfa5f0a307a

Fix GRND_NONBLOCK flag when calling getrandom. I screwed up in 56b6c714c9 and got the direction of this condition backwards. This doesn't cause a security problem because: a) wait_for_entropy will ensure that the pool is initialised. b) if GRNG_NONBLOCK is set when not expected, any EAGAIN will cause an abort anyway. However, when coupled with opportunistic entropy collection on platforms with RDRAND, this could cause an unexpected blocking getrandom call. This this change, `strace -e getrandom bssl rand 1` shows two getrandom calls with GRNG_NONBLOCK set, as expected. (The first being the probe to check whether the kernel supports getrandom, and the second being the opportunistic entropy gathering to augment RDRAND.) Change-Id: I98ed1cef90df510f24cf2df1fba9b886fcbf3355 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38204 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha a7a75f208caea8a303615724d4cc5f4e8dfb9695

Do fewer trial divisions for larger RSA keygens. Now that Miller-Rabin can reject composites faster, we can do fewer trial divisions. Halving the table seems to improve things for RSA-3072 and RSA-4096. I left RSA-2048 alone since measurements with it halved were a bit more of a wash. (Although now that I've left it alone, it's gotten faster, so these numbers are generally noisy.) Before: Did 320 RSA 2048 key-gen operations in 30132984us (10.6 ops/sec) min: 27703us, median: 81774us, max: 375687us Did 84 RSA 3072 key-gen operations in 30166627us (2.8 ops/sec) min: 86961us, median: 322184us, max: 1170392us Did 30 RSA 4096 key-gen operations in 30644802us (1.0 ops/sec) min: 260916us, median: 772364us, max: 2743435us After: Did 345 RSA 2048 key-gen operations in 30103781us (11.5 ops/sec) min: 23359us, median: 75033us, max: 267159us Did 91 RSA 3072 key-gen operations in 30185495us (3.0 ops/sec) min: 72531us, median: 267385us, max: 1119039us Did 38 RSA 4096 key-gen operations in 30473203us (1.2 ops/sec) min: 228529us, median: 720027us, max: 2039681us Change-Id: I52d431347a70572034ced5b7778a2edac8f15173 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38168 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 31302a473afcde1bc60acdeab0b0cb0498b5aa66

Fix up BN_GENCB_call calls. Use the constants when defined. Also OpenSSL uses 0-indexed iteration counts rather than 1-indexed. This likely changed when we tried to align with the 1-indexed FIPS 186-4 algorithm. Also fix the safe prime call. BN_GENCB_call(cb, i, c1 - 1) doesn't make sense since the first parameter should be an event constant. OpenSSL does BN_GENCB_call(cb, 2, c1 - 1). This also doesn't make sense. OpenSSL documents 2 as meaning the prime has been found. That function is interleaving the p and (p-1)/2 checks to save the full iteration count on p if (p-1)/2 is composite anyway. That also doesn't work because the blinding mechanism runs even if the iteration count is 1, so we're actually paying for the blinding four times. Add a TODO to address this. (I can only assume we just never try to generate safe primes. Moreover, we don't even use BN_generate_prime_ex in RSA keygen. Still, that function needs work.) Change-Id: I6f0b7cd10da28484362c92db0c806c1c3045d415 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38169 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha a93bebafb891227d755f5d23e7be94de7174705f

Rename the last remnants of the early_data_info extension. The extension was renamed to just 'early_data' at some point in TLS 1.3's development. Change-Id: I9d1de10aaeb347237b52a226e9533307f5c269ce Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38224 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha eec840da626eadebb43eba82c145abae308f81fc

Switch probable_prime to rejection sampling. This is much more straightforward, and aligns better with what our actual RSA key generation logic does. Change-Id: I45f368b10f42558b91c2d022847505ddab2f7094 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38170 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 9709ad52eb7cba2754256c66f4c7129cc6d244a7

Fix $OPENSSL_ia32cap handling. The comment says that an "0x" prefix indicates a hex value. However we always passed PRIu64 as the format specifier for |sscanf|, and |sscanf| isn't documented to handle an 0x prefix expect for "i"-family format specifiers. With |PRIu64|, |sscanf| reads any leading "0x" as just zero. Instead, check for "0x" ourselves and use |PRIx64| if found to parse hex values. Change-Id: Id5ed7009d30902022e5ee640e8931bf1431dedc0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38264 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Pete Bentley

commit sha 76918d016414bf1d71a86d28239566fbcf8aacf0

break-hash.go: Search ELF dynamic symbols if symbols not found. Allows the utility to work on shared libraries. Also, don't printf the output from hex.Dump() as it may contain formatting chars such as %. Change-Id: I3c091436271c132417fd0212955a6575ef57af50 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38244 Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 3e502c84f049d1cad180d61257971b733d836df1

Add test for urandom.c This change adds a test to try and prevent errors like b8f760191e. Since it's challenging to test this code, it uses ptrace to capture a trace of the PRNG behaviour and checks that the observed behaviour matches a much smaller model of the code. The model is hopefully easier to read and believe correct. Change-Id: I00b811dc5692e2fbe3dcc16c622d4eb706f16ce0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38265 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 20ae5e6f6cc8925dd9185f23e7835cfe85ed5f6e

Correct relative path. This path has always had one-too-few “..” elements since the file first appeared, but everyone seems to have lived with it, presumably because /include is in the search path and the compiler tries relative to that. Change-Id: I30006209ad74d064ded5dd2cd34b1f14806dcffe Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38344 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha da8caf5b1029b93d482702759058ac993a39bcc5

Add sanity checks to FIPS module construction. If -ffunction-sections or -fdata-sections is enabled when doing a FIPS shared build, the linker script won't do what's expected and will silently end up including very little (or nothing) in the integrity check. This changes alters the linker script to discard any text or data sections other than the main one, which should make this failure much more obvious. Also, add assertions (that are always enabled) in the module to check that a few obvious things that should be inside the module boundaries actually are. Change-Id: I91178e213a28a7c0c4a38155974e452cd9d558d1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38324 Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha e481d94a6fbdc2402be8ae26c0ccbc3bc8969ecb

Fix the standalone Android FIPS build. Change-Id: Idce6c93f5a37e1f05afaa6fb928e15b92d75e911 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38365 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 7de9498a886ab28fe4a6023c33cf98524c1090ff

Add urandom_test to all_tests.json Change-Id: I4e30bc8b8c1bd1215f516a6c89735782cfbf8ef5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38284 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 7f02881e96e51f1873afcf384d02f782b48967ca

Drop CECPQ2b code. The experiment which motivated CECPQ2b has concluded (although the results haven't been published yet) and the SIKE code is causing some issues for gRPC in gprc/grpc#20100. Also, this is code size that takes up space in Android etc. Change-Id: I43b0b8c420f236c0fe9b40bf2517d2fde98495d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38384 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Van Cleve

commit sha c951e5560b728e8be1f71caf91051d386b1502e3

Reenable bn_div fuzzer. It looks like the bn_div fuzzer was inadvertently removed from fuzz/'s CMakeLists during an earlier refactor [1]. This change adds it back. [1]: https://boringssl-review.googlesource.com/c/boringssl/+/31324/ Change-Id: I8bb4b224eedff60cc5cd6df7fa39d9c39d499a56 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38424 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 13 days

push eventgoogle/boringssl

Adam Langley

commit sha 2865bce1b2ede077074f36f29e81ba4696185b23

FIPS.md: document some recent Android changes. Change-Id: I48cc5fc6211a1a557cfeb1aad5688753bc7b5dfd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38124 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 5cf3298140ae4e4d219a0703c5280fa327c361fa

Fix the FIPS + fuzzing build. Recent changes to the PRNG seeding in FIPS mode broke the build when trying to build with both FIPS and fuzzing enabled. Change-Id: I069b4af1fdd4efaef96e3e3b3a1e0197faabe2e1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38184 Reviewed-by: Matt Braithwaite <mab@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 18d145e651b6c80ae562bcf41ff804aaad674595

Extract and test the deterministic part of Miller-Rabin. This way we test not only that we match expectations for primes and composites but that the core test correctly reports false witnesses. I made an initial attempt to gather some interesting test input, but probably one can do better. Change-Id: I7c29afb534bd6980ef42a893e86d86bd44af8349 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38164 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha fba30c389c1c23b00f5f60953d7ad0374f9cc105

Break early on composites in the primality test. |a| is usually much smaller than |w_bits|. We only need to loop up to |w_bits| and hide |a| when the value is possibly composite. If Miller-Rabin has not hit -1 by then, break early. This speeds up RSA keygen by a bit. Before: Did 248 RSA 2048 key-gen operations in 30041496us (8.3 ops/sec) min: 31690us, median: 109097us, max: 373911us Did 71 RSA 3072 key-gen operations in 30096719us (2.4 ops/sec) min: 108650us, median: 370844us, max: 1768070us Did 27 RSA 4096 key-gen operations in 32829007us (0.8 ops/sec) min: 205485us, median: 1107051us, max: 4035040us After: Did 340 RSA 2048 key-gen operations in 30026342us (11.3 ops/sec) min: 24681us, median: 77749us, max: 350477us Did 67 RSA 3072 key-gen operations in 30089075us (2.2 ops/sec) min: 75070us, median: 394220us, max: 1101562us Did 38 RSA 4096 key-gen operations in 30283788us (1.3 ops/sec) min: 284947us, median: 742688us, max: 1970468us Change-Id: If1b48e9306c3fe1be56c304143e206c3bdb3301d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38165 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 841a40a2769bb92e395906b547464546f886785c

Add some notes on RSA key generation performance. Change-Id: I8c0cadddcfc7d8b14adbc3ed3b75332859deea42 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38166 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 642664838ae91b943c6fd061f595253ac2ebe06c

Simplify bn_miller_rabin_iteration slightly. We don't need both mask variables. If we know we have a composite witness, we return immediately, so the only time we mask off instructions is when we know we have a nonwitness. Change-Id: I2b99f3114a79ce2dc1a37706835d2abfe93a716e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38167 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha f3bd757ee5e7ad409d2fdf7c3bb5fdfa5f0a307a

Fix GRND_NONBLOCK flag when calling getrandom. I screwed up in 56b6c714c9 and got the direction of this condition backwards. This doesn't cause a security problem because: a) wait_for_entropy will ensure that the pool is initialised. b) if GRNG_NONBLOCK is set when not expected, any EAGAIN will cause an abort anyway. However, when coupled with opportunistic entropy collection on platforms with RDRAND, this could cause an unexpected blocking getrandom call. This this change, `strace -e getrandom bssl rand 1` shows two getrandom calls with GRNG_NONBLOCK set, as expected. (The first being the probe to check whether the kernel supports getrandom, and the second being the opportunistic entropy gathering to augment RDRAND.) Change-Id: I98ed1cef90df510f24cf2df1fba9b886fcbf3355 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38204 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha a7a75f208caea8a303615724d4cc5f4e8dfb9695

Do fewer trial divisions for larger RSA keygens. Now that Miller-Rabin can reject composites faster, we can do fewer trial divisions. Halving the table seems to improve things for RSA-3072 and RSA-4096. I left RSA-2048 alone since measurements with it halved were a bit more of a wash. (Although now that I've left it alone, it's gotten faster, so these numbers are generally noisy.) Before: Did 320 RSA 2048 key-gen operations in 30132984us (10.6 ops/sec) min: 27703us, median: 81774us, max: 375687us Did 84 RSA 3072 key-gen operations in 30166627us (2.8 ops/sec) min: 86961us, median: 322184us, max: 1170392us Did 30 RSA 4096 key-gen operations in 30644802us (1.0 ops/sec) min: 260916us, median: 772364us, max: 2743435us After: Did 345 RSA 2048 key-gen operations in 30103781us (11.5 ops/sec) min: 23359us, median: 75033us, max: 267159us Did 91 RSA 3072 key-gen operations in 30185495us (3.0 ops/sec) min: 72531us, median: 267385us, max: 1119039us Did 38 RSA 4096 key-gen operations in 30473203us (1.2 ops/sec) min: 228529us, median: 720027us, max: 2039681us Change-Id: I52d431347a70572034ced5b7778a2edac8f15173 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38168 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha 31302a473afcde1bc60acdeab0b0cb0498b5aa66

Fix up BN_GENCB_call calls. Use the constants when defined. Also OpenSSL uses 0-indexed iteration counts rather than 1-indexed. This likely changed when we tried to align with the 1-indexed FIPS 186-4 algorithm. Also fix the safe prime call. BN_GENCB_call(cb, i, c1 - 1) doesn't make sense since the first parameter should be an event constant. OpenSSL does BN_GENCB_call(cb, 2, c1 - 1). This also doesn't make sense. OpenSSL documents 2 as meaning the prime has been found. That function is interleaving the p and (p-1)/2 checks to save the full iteration count on p if (p-1)/2 is composite anyway. That also doesn't work because the blinding mechanism runs even if the iteration count is 1, so we're actually paying for the blinding four times. Add a TODO to address this. (I can only assume we just never try to generate safe primes. Moreover, we don't even use BN_generate_prime_ex in RSA keygen. Still, that function needs work.) Change-Id: I6f0b7cd10da28484362c92db0c806c1c3045d415 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38169 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha a93bebafb891227d755f5d23e7be94de7174705f

Rename the last remnants of the early_data_info extension. The extension was renamed to just 'early_data' at some point in TLS 1.3's development. Change-Id: I9d1de10aaeb347237b52a226e9533307f5c269ce Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38224 Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Benjamin

commit sha eec840da626eadebb43eba82c145abae308f81fc

Switch probable_prime to rejection sampling. This is much more straightforward, and aligns better with what our actual RSA key generation logic does. Change-Id: I45f368b10f42558b91c2d022847505ddab2f7094 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38170 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 9709ad52eb7cba2754256c66f4c7129cc6d244a7

Fix $OPENSSL_ia32cap handling. The comment says that an "0x" prefix indicates a hex value. However we always passed PRIu64 as the format specifier for |sscanf|, and |sscanf| isn't documented to handle an 0x prefix expect for "i"-family format specifiers. With |PRIu64|, |sscanf| reads any leading "0x" as just zero. Instead, check for "0x" ourselves and use |PRIx64| if found to parse hex values. Change-Id: Id5ed7009d30902022e5ee640e8931bf1431dedc0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38264 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Pete Bentley

commit sha 76918d016414bf1d71a86d28239566fbcf8aacf0

break-hash.go: Search ELF dynamic symbols if symbols not found. Allows the utility to work on shared libraries. Also, don't printf the output from hex.Dump() as it may contain formatting chars such as %. Change-Id: I3c091436271c132417fd0212955a6575ef57af50 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38244 Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 3e502c84f049d1cad180d61257971b733d836df1

Add test for urandom.c This change adds a test to try and prevent errors like b8f760191e. Since it's challenging to test this code, it uses ptrace to capture a trace of the PRNG behaviour and checks that the observed behaviour matches a much smaller model of the code. The model is hopefully easier to read and believe correct. Change-Id: I00b811dc5692e2fbe3dcc16c622d4eb706f16ce0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38265 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

Adam Langley

commit sha 20ae5e6f6cc8925dd9185f23e7835cfe85ed5f6e

Correct relative path. This path has always had one-too-few “..” elements since the file first appeared, but everyone seems to have lived with it, presumably because /include is in the search path and the compiler tries relative to that. Change-Id: I30006209ad74d064ded5dd2cd34b1f14806dcffe Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38344 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha da8caf5b1029b93d482702759058ac993a39bcc5

Add sanity checks to FIPS module construction. If -ffunction-sections or -fdata-sections is enabled when doing a FIPS shared build, the linker script won't do what's expected and will silently end up including very little (or nothing) in the integrity check. This changes alters the linker script to discard any text or data sections other than the main one, which should make this failure much more obvious. Also, add assertions (that are always enabled) in the module to check that a few obvious things that should be inside the module boundaries actually are. Change-Id: I91178e213a28a7c0c4a38155974e452cd9d558d1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38324 Reviewed-by: Adam Langley <agl@google.com>

view details

David Benjamin

commit sha e481d94a6fbdc2402be8ae26c0ccbc3bc8969ecb

Fix the standalone Android FIPS build. Change-Id: Idce6c93f5a37e1f05afaa6fb928e15b92d75e911 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38365 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 7de9498a886ab28fe4a6023c33cf98524c1090ff

Add urandom_test to all_tests.json Change-Id: I4e30bc8b8c1bd1215f516a6c89735782cfbf8ef5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38284 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

Adam Langley

commit sha 7f02881e96e51f1873afcf384d02f782b48967ca

Drop CECPQ2b code. The experiment which motivated CECPQ2b has concluded (although the results haven't been published yet) and the SIKE code is causing some issues for gRPC in gprc/grpc#20100. Also, this is code size that takes up space in Android etc. Change-Id: I43b0b8c420f236c0fe9b40bf2517d2fde98495d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38384 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

David Van Cleve

commit sha c951e5560b728e8be1f71caf91051d386b1502e3

Reenable bn_div fuzzer. It looks like the bn_div fuzzer was inadvertently removed from fuzz/'s CMakeLists during an earlier refactor [1]. This change adds it back. [1]: https://boringssl-review.googlesource.com/c/boringssl/+/31324/ Change-Id: I8bb4b224eedff60cc5cd6df7fa39d9c39d499a56 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38424 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 13 days

push eventgoogle/boringssl

Adam Langley

commit sha 7964a1d6768650b8d34da23842f3f14851722afc

Check for overflow in massive mallocs. Hopefully it never happens, but a malloc of nearly the whole address space should fail cleanly. Change-Id: I82499e3236a1a485f5518b1c048899b1df3e8488 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39864 Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha fd123155ae590f0ba430c71fbe0bd331886cb0e3

update master-with-bazel from master branch

view details

push time in 13 days

push eventgoogle/boringssl

Adam Langley

commit sha 7964a1d6768650b8d34da23842f3f14851722afc

Check for overflow in massive mallocs. Hopefully it never happens, but a malloc of nearly the whole address space should fail cleanly. Change-Id: I82499e3236a1a485f5518b1c048899b1df3e8488 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39864 Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 13 days

push eventgoogle/boringssl

David Benjamin

commit sha 7e43e2e8eecc9114f829e6d75cc3c04d1af57504

Add more convenient RSA getters. OpenSSL 1.1.0's RSA getters can be inconvenient because they return a number of fields via output parameters. OpenSSL 1.1.1 adds individual getters for each of the fields, which is a bit simpler. Align with them. Note our OPENSSL_VERSION_NUMBER is still 1.1.0. Adding these functions may cause friction with third-party packages which polyfill these functions based on OPENSSL_VERSION_NUMBER, though none appear to be doing this right now. Between this and TLS 1.3, we probably should switch the version to 1.1.1 at some point anyway. Change-Id: Iada5a0315c403cc221688af53fc4ba165d65e99c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39944 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 16 days

push eventgoogle/boringssl

David Benjamin

commit sha 7e43e2e8eecc9114f829e6d75cc3c04d1af57504

Add more convenient RSA getters. OpenSSL 1.1.0's RSA getters can be inconvenient because they return a number of fields via output parameters. OpenSSL 1.1.1 adds individual getters for each of the fields, which is a bit simpler. Align with them. Note our OPENSSL_VERSION_NUMBER is still 1.1.0. Adding these functions may cause friction with third-party packages which polyfill these functions based on OPENSSL_VERSION_NUMBER, though none appear to be doing this right now. Between this and TLS 1.3, we probably should switch the version to 1.1.1 at some point anyway. Change-Id: Iada5a0315c403cc221688af53fc4ba165d65e99c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39944 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha fd590decc786447067664e447e53d1244b46e720

update master-with-bazel from master branch

view details

push time in 16 days

issue commentw3c/webauthn

BLE Resolvable Private Address resolution using IRK

This is the W3C group that defines WebAuthn, the Web Platform API. WebAuthn only suggests that BLE might be used as a transport and doesn't define anything about how it's implemented. (That's handled by FIDO.) Also, the WebAuthn API doesn't have any BLE addresses in it.

It seems that perhaps this is a bug report for a specific platform implementation of BLE support?

rjhallock6

comment created time in 16 days

push eventgoogle/boringssl

David Benjamin

commit sha 1766935f767e943b98dfd4b0f3872f2521c8c6e8

Remove SSL_CTX_set_ed25519_enabled. We never ended up using this, and callers can still configure SSL_CTX_set_verify_algorithm_prefs to enable Ed25519 on the receiving side. (On the sending side, this API was never needed because it's a function of what certificate you configure.) This was just a way to tweak the default without requiring callers restate the order. Change-Id: I38d7f91d85430f37fc7e278d77466e78a0cbfa0d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39848 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 16 days

push eventgoogle/boringssl

David Benjamin

commit sha 1766935f767e943b98dfd4b0f3872f2521c8c6e8

Remove SSL_CTX_set_ed25519_enabled. We never ended up using this, and callers can still configure SSL_CTX_set_verify_algorithm_prefs to enable Ed25519 on the receiving side. (On the sending side, this API was never needed because it's a function of what certificate you configure.) This was just a way to tweak the default without requiring callers restate the order. Change-Id: I38d7f91d85430f37fc7e278d77466e78a0cbfa0d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39848 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha cc80b0dacfd0af412f5a45c20cd050f6f3deec08

update master-with-bazel from master branch

view details

push time in 16 days

push eventgoogle/boringssl

David Benjamin

commit sha 6ab75bf21fd8f09a85c36775d4b5a3b4e4a76d99

Improve signature algorithm tests. ecdsa_sha1 and ecdsa_secp521_sha512 are disabled by default but a caller could still enable them by configuring the verify preferences. Improve the tests to distinguish these cases better. Also, as this is getting unwieldy, cut down on duplicated code between the client and server signatures. Change-Id: I1530f4cb43d8e9d675f7fdc4693034287fcac153 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39847 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha 6ab75bf21fd8f09a85c36775d4b5a3b4e4a76d99

Improve signature algorithm tests. ecdsa_sha1 and ecdsa_secp521_sha512 are disabled by default but a caller could still enable them by configuring the verify preferences. Improve the tests to distinguish these cases better. Also, as this is getting unwieldy, cut down on duplicated code between the client and server signatures. Change-Id: I1530f4cb43d8e9d675f7fdc4693034287fcac153 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39847 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha dc350d40ea98333cde12da63b5fced3dd49c3e4c

update master-with-bazel from master branch

view details

push time in 17 days

push eventgoogle/boringssl

Adam Langley

commit sha 2a4ce172436b332374c2abeac3bfefcbf9736496

bazel: explicitly load C++ rules Starting with Bazel 3.0, C++ rules will require loads. See https://github.com/bazelbuild/bazel/issues/8743 Thanks to Yannic Bonenberger for noting this in https://boringssl-review.googlesource.com/c/boringssl/+/39825 Change-Id: I8e274c82ade6c7ec569989026190f6a0a88b47ed Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39924 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 17 days

push eventgoogle/boringssl

Adam Langley

commit sha 2a4ce172436b332374c2abeac3bfefcbf9736496

bazel: explicitly load C++ rules Starting with Bazel 3.0, C++ rules will require loads. See https://github.com/bazelbuild/bazel/issues/8743 Thanks to Yannic Bonenberger for noting this in https://boringssl-review.googlesource.com/c/boringssl/+/39825 Change-Id: I8e274c82ade6c7ec569989026190f6a0a88b47ed Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39924 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha d3d94a0af6ca1873156f501b71ae856e643cfe00

update master-with-bazel from master branch

view details

push time in 17 days

push eventgoogle/boringssl

Adam Langley

commit sha fbea9de16398321ed245e3271f4ed0a8149a5e6a

Check enum values in handoff. Casting an out-of-range value to an enum is undefined behaviour in C. Bug: oss-fuzz:20546 Change-Id: I11c6bc533b898430bd791e3cdcb271943b95c101 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39904 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 17 days

push eventgoogle/boringssl

Adam Langley

commit sha fbea9de16398321ed245e3271f4ed0a8149a5e6a

Check enum values in handoff. Casting an out-of-range value to an enum is undefined behaviour in C. Bug: oss-fuzz:20546 Change-Id: I11c6bc533b898430bd791e3cdcb271943b95c101 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39904 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 24610081a5cebed5274865ec6e20348f4be35607

update master-with-bazel from master branch

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha 921bb9e224a9c5b082c0d42cd6c76cb2f9759ee6

Restore fuzz/cert_corpus. This was accidentally deleted in https://boringssl-review.googlesource.com/c/boringssl/+/39805 Change-Id: Iba1ee7b03e0e531a4aa86ec6c048523d87bd2c72 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39884 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha cf5d9be80a0b38bbe16ed24fa0d93d5327b5f31e

update master-with-bazel from master branch

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha 921bb9e224a9c5b082c0d42cd6c76cb2f9759ee6

Restore fuzz/cert_corpus. This was accidentally deleted in https://boringssl-review.googlesource.com/c/boringssl/+/39805 Change-Id: Iba1ee7b03e0e531a4aa86ec6c048523d87bd2c72 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39884 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha bf17f4f6f1eaac59a5f757a220d5e86793a4a842

Add a -sigalgs option to bssl client. Change-Id: I6247e02c6a9a9cc6ff5005eafe96f89f864cb12c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39846 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 7e89691f5af1abc4ea35c1377bfba2b49fa7625b

update master-with-bazel from master branch

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha bf17f4f6f1eaac59a5f757a220d5e86793a4a842

Add a -sigalgs option to bssl client. Change-Id: I6247e02c6a9a9cc6ff5005eafe96f89f864cb12c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39846 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha f0a815cce504269049c18d767c72ddfd41378b24

Add SSL_set_verify_algorithm_prefs. We already had the state for it, but no API. This will allow us to configure the signature preferences individually per socket in Chromium and get a better measurement for how often SHA-1 in TLS 1.2 is still needed. See associated bug for details. Bug: chromium:658905 Change-Id: Id6198afc91f8275492995992e03d75a7ff328909 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39845 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 82b9f704ec49f521ca8acc7d2cfed03b92a807c1

update master-with-bazel from master branch

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha f0a815cce504269049c18d767c72ddfd41378b24

Add SSL_set_verify_algorithm_prefs. We already had the state for it, but no API. This will allow us to configure the signature preferences individually per socket in Chromium and get a better measurement for how often SHA-1 in TLS 1.2 is still needed. See associated bug for details. Bug: chromium:658905 Change-Id: Id6198afc91f8275492995992e03d75a7ff328909 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39845 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 17 days

push eventgoogle/boringssl

David Benjamin

commit sha ebad508ef111ef13106019f6e9b22bdae7bf57ef

Switch verify sigalg pref functions to SSL_HANDSHAKE. Functions that take SSL* do not necessarily have an ssl->config available because it is released post-handshake, whereas hs->config can be accessed without a null check. Change-Id: I3d9f3838c1f2d79f92beac363a90fb6046671053 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39844 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 1372a681753b4eb8dbdf8db2cbd30d6981bd1a76

update master-with-bazel from master branch

view details

push time in 18 days

push eventgoogle/boringssl

David Benjamin

commit sha ebad508ef111ef13106019f6e9b22bdae7bf57ef

Switch verify sigalg pref functions to SSL_HANDSHAKE. Functions that take SSL* do not necessarily have an ssl->config available because it is released post-handshake, whereas hs->config can be accessed without a null check. Change-Id: I3d9f3838c1f2d79f92beac363a90fb6046671053 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39844 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in 18 days

issue commentgolang/go

dev.boringcrypto: update security policy reference

we have not updated the BoringCrypto module itself. (Should we do that when a new validation comes through?)

Ideally, yes.

Can we / should we update the reference to 140sp3318.pdf?

The reference should match the BoringCrypto module in use.

akashgiri

comment created time in 18 days

push eventgoogle/boringssl

David Schinazi

commit sha 10165d82c16a9cab4a61569eaea9f0fadb36346c

Add SSL_AD_NO_APPLICATION_PROTOCOL This is based on AGL's comment on https://boringssl-review.googlesource.com/c/boringssl/+/39784 Change-Id: I3204a64084288a2c025bc3e4c769a153126a1f9f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39785 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

push time in 18 days

push eventgoogle/boringssl

David Schinazi

commit sha 10165d82c16a9cab4a61569eaea9f0fadb36346c

Add SSL_AD_NO_APPLICATION_PROTOCOL This is based on AGL's comment on https://boringssl-review.googlesource.com/c/boringssl/+/39784 Change-Id: I3204a64084288a2c025bc3e4c769a153126a1f9f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39785 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 3b34138cd1ebf299d589652c4858ecf66df190b1

update master-with-bazel from master branch

view details

push time in 18 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 3d53d1ffe683070764048747ce18b6a29f3f968a

Refresh corpora due to TLS 1.3 changes in handoff serialization. Along the way, update |refresh_ssl_corpora.sh| to use the right handshaker path. How to: (rm -rf build-fuzz && mkdir build-fuzz && cd build-fuzz && CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 .. && ninja all) (rm -rf build-no-fuzzer-mode && mkdir build-no-fuzzer-mode && cd build-no-fuzzer-mode && CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 -DNO_FUZZER_MODE=1 .. && ninja all) (cd ~/boringssl/fuzz && ../fuzz/refresh_ssl_corpora.sh ../build-fuzz ../build-no-fuzzer-mode ) 2>&1 | tee /tmp/refresh-log Change-Id: I1115dfe45d25bd74ace1048c80d614afb26223ee Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39805 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Matt Braithwaite <mab@google.com>

view details

push time in 18 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 3d53d1ffe683070764048747ce18b6a29f3f968a

Refresh corpora due to TLS 1.3 changes in handoff serialization. Along the way, update |refresh_ssl_corpora.sh| to use the right handshaker path. How to: (rm -rf build-fuzz && mkdir build-fuzz && cd build-fuzz && CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 .. && ninja all) (rm -rf build-no-fuzzer-mode && mkdir build-no-fuzzer-mode && cd build-no-fuzzer-mode && CC=clang CXX=clang++ cmake -GNinja -DFUZZ=1 -DNO_FUZZER_MODE=1 .. && ninja all) (cd ~/boringssl/fuzz && ../fuzz/refresh_ssl_corpora.sh ../build-fuzz ../build-no-fuzzer-mode ) 2>&1 | tee /tmp/refresh-log Change-Id: I1115dfe45d25bd74ace1048c80d614afb26223ee Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39805 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Matt Braithwaite <mab@google.com>

view details

BoringSSL Robot

commit sha 9c26ff06c7a43df3028a5064fe1c11a6739e9eaa

update master-with-bazel from master branch

view details

push time in 18 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 9e23361aa07af48c35e6142902009387a797125f

handoff: set |enable_early_data| as part of handback. This doesn't change the serialization: it just adds |enable_early_data| to the list of early data fields that get updated by SSL_apply_handback(). This is needed because, for example, add_new_session_tickets(), which runs after handback, performs certain actions iff |enable_early_data| is set. Plus it just seems cleaner. Change-Id: Ibcdb745ff9bcbeb2af2475f69f9f798937e7ee63 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39804 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Matt Braithwaite <mab@google.com>

view details

push time in 19 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 9e23361aa07af48c35e6142902009387a797125f

handoff: set |enable_early_data| as part of handback. This doesn't change the serialization: it just adds |enable_early_data| to the list of early data fields that get updated by SSL_apply_handback(). This is needed because, for example, add_new_session_tickets(), which runs after handback, performs certain actions iff |enable_early_data| is set. Plus it just seems cleaner. Change-Id: Ibcdb745ff9bcbeb2af2475f69f9f798937e7ee63 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39804 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Matt Braithwaite <mab@google.com>

view details

BoringSSL Robot

commit sha a14d2089dd47e73134de3e86e2ea95aad16dae7e

update master-with-bazel from master branch

view details

push time in 19 days

issue closedgolang/go

dev.boringcrypto: AES_128_CBC_SHA and AES_256_CBC_SHA missing in defaultFIPSCipherSuites

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

What version of Go are you using (go version)?

<pre> $ go version go version devel +35ba528 Mon Jul 2 18:35:13 2018 -0400 linux/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

Ubuntu 18.04 <details><summary><code>go env</code> Output</summary><br><pre> $ go env GOARCH="amd64" GOBIN="" GOCACHE="/root/.cache/go-build" GOEXE="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/bld" GORACE="" GOROOT="/usr/local/go" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build346953438=/tmp/go-build -gno-record-gcc-switches" </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

Just an inquiry why following cipher suites are not available in the defaultFIPSCipherSuites in go/src/crypto/tls/boring.go

TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,

What did you expect to see?

As per the wiki here

AES128-SHA and AES256-SHA are both compatible in TLS 1.0 and 1.1 as well as TLS 1.2

What did you see instead?

I see these cipher suites are missing.

closed time in 19 days

saurabhsuniljain

issue commentgolang/go

dev.boringcrypto: AES_128_CBC_SHA and AES_256_CBC_SHA missing in defaultFIPSCipherSuites

The CBC code wrapped from BoringSSL is the CBC implementation exported by the FIPS module, which does not handle TLS record decoding in constant-time. Also, the CBC modes are vestigial and have been removed from TLS 1.3 so, any time we're write cipher suite lists, we're trying not to include them.

saurabhsuniljain

comment created time in 19 days

push eventgoogle/boringssl

David Schinazi

commit sha 032fc660bc9b208926a3b1711f8ec7ec1dacceda

Add 109 and 120 to SSL_alert_desc_string_long Change-Id: Ie50fcbabec73bf14895c4eaba134409e010679c4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39784 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 8e1e005a3fe4e0b5a579686c2b354e925ee2f60f

update master-with-bazel from master branch

view details

push time in 19 days

push eventgoogle/boringssl

David Schinazi

commit sha 032fc660bc9b208926a3b1711f8ec7ec1dacceda

Add 109 and 120 to SSL_alert_desc_string_long Change-Id: Ie50fcbabec73bf14895c4eaba134409e010679c4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39784 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 19 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 6192ccbbfde0033ca7e44ac861bc2dab440f2fdb

runner: enable split handshake tests for TLS 1.3. Although the new tests are enabled by default, there is a flag to (continue to) skip them. This is to allow for inter-version compatibility testing to be performed without a monstrous number of failures from old versions that don't yet have TLS 1.3 support. Change-Id: I9f5e201a21f775442859e127c906b5f77ad8755b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39388 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 19 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 6192ccbbfde0033ca7e44ac861bc2dab440f2fdb

runner: enable split handshake tests for TLS 1.3. Although the new tests are enabled by default, there is a flag to (continue to) skip them. This is to allow for inter-version compatibility testing to be performed without a monstrous number of failures from old versions that don't yet have TLS 1.3 support. Change-Id: I9f5e201a21f775442859e127c906b5f77ad8755b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39388 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha d3957e2285bb05384f7d0df5e9bebf55f6a83fbb

update master-with-bazel from master branch

view details

push time in 19 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha f3c98ce9b7f1cb076b66817de064a9c73493b89b

Make TLS 1.3 split handshakes work with early data. Change-Id: Ib051447a4bdde4e08e84e54ec619d47535bb472c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39384 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 7b9e2c9f4f0ba265ddeb78c164271148783fc3b0

update master-with-bazel from master branch

view details

push time in 20 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha f3c98ce9b7f1cb076b66817de064a9c73493b89b

Make TLS 1.3 split handshakes work with early data. Change-Id: Ib051447a4bdde4e08e84e54ec619d47535bb472c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39384 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 20 days

issue openedw3c/webauthn

Signature counters exist in makeCredential too

The section of the spec about signature counters doesn't mention that they're provided by makeCredential as well as in assertions. The semantics of the makeCredential signature counter are missing.

For U2F authenticators, the signature counter in the makeCredential response will always be zero. At least some CTAP2 authenticators provide a non-zero counter. At least some CTAP2 authenticators increment a global signature counter when performing a makeCredential.

Step 10 of the makeCredential algorithm does say things, but it's a little at odds with reality: nearly all U2F authenticators use a global signature counter but browsers have to make an authenticatorData from a U2F registration response (which doesn't have a counter) and thus insert a value of zero, not the global value.

If we believe that other parts of the spec are correct, then the section on signature counters needs to be updated to talk about makeCredential counters.

created time in 20 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 093a823923f3b9c413427c45015c8d452dc9c349

Split half-RTT tickets out into a separate TLS 1.3 state. This is prefactoring to allow a split handshake to be handed back prior to sending the half-RTT ticket. Change-Id: Ib5c335b3109a024391c2ec2cab0749eae43f4646 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39744 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha cfea96fa0c67768e27dfdf8dcd76e905f48ce44b

update master-with-bazel from master branch

view details

push time in 25 days

push eventgoogle/boringssl

Matthew Braithwaite

commit sha 093a823923f3b9c413427c45015c8d452dc9c349

Split half-RTT tickets out into a separate TLS 1.3 state. This is prefactoring to allow a split handshake to be handed back prior to sending the half-RTT ticket. Change-Id: Ib5c335b3109a024391c2ec2cab0749eae43f4646 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39744 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in 25 days

issue openedw3c/webauthn

Clarity on transport hints

John says that the wording about transport hints in the spec isn't very accurate now. We should tell RPs to store the hints with the credential, return them during getAssertion, and otherwise never look at or touch them.

created time in 25 days

push eventgoogle/boringssl

Augusto Righetto

commit sha bc7e2cb92d948de5f437e5eef2b1c3ad6281bb35

Use BCryptGenRandom when building as Windows UWP app. RtlGenRandom is a legacy API that might be altered and is unavailable for UWP apps. BCryptGenRandom is the recommended API for generating random numbers on UWP. This change causes BCryptGenRandom to be used for UWP apps and RtlGenRandom to be used on non-UWP apps (i.e. desktop apps). For non-UWP configurations, RtlGenRandom is used instead of BCryptGenRandom to avoid accessing resources that may be unavailable inside the Chromium sandbox. Bug: 307 Change-Id: I49f445198b7b4f300a752f45e221a2875d17099e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39584 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha aee09c35c59aa0e12700a426f2c6400af24bd475

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

Augusto Righetto

commit sha bc7e2cb92d948de5f437e5eef2b1c3ad6281bb35

Use BCryptGenRandom when building as Windows UWP app. RtlGenRandom is a legacy API that might be altered and is unavailable for UWP apps. BCryptGenRandom is the recommended API for generating random numbers on UWP. This change causes BCryptGenRandom to be used for UWP apps and RtlGenRandom to be used on non-UWP apps (i.e. desktop apps). For non-UWP configurations, RtlGenRandom is used instead of BCryptGenRandom to avoid accessing resources that may be unavailable inside the Chromium sandbox. Bug: 307 Change-Id: I49f445198b7b4f300a752f45e221a2875d17099e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39584 Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com>

view details

push time in a month

Pull request review commentrust-lang/rfcs

added secret types rfc

+- Feature Name: Secret Types +- Start Date: 2020-01-23+- RFC PR: +- Rust Issue: ++# Summary+[summary]: #summary++The goal is to provide primitive data types that can be used to traffic in transient secrets in code that are important to not accidentally leak. These new primitives would be used in conjunction with an in-progress LLVM RFC to ensure important security invariants like secret-independent runtime are maintained throughout the compilation process. Note that we explicitly do not want secret_isize and secret_usize, because we do not want to index based on secrets.++- secret_i8+- secret_i16 +- secret_i32+- secret_i64+- secret_i128+- secret_u8+- secret_u16 +- secret_u32+- secret_u64+- secret_u128+- secret_bool+++# Motivation+[motivation]: #motivation++Applications deal with sensitive data all the time to varying degrees of success. Sensitive data is not limited to information like cryptographic codes and keys, but could also be data like passwords or PII such as social security numbers. Accidental secret leakage is a challenge for both programmers, who might mix secret and public data inadvertently, and compilers, which might use optimizations that reveal secrets via side-channels.++Writing cryptographic and other security critical code in high-level languages like Rust is attractive for numerous reasons. High level languages are generally more readable and accessible to developers and reviewers, leading to higher quality, more secure code. It also allows the integration of cryptographic code with the rest of an application without requiring the use of any FFI. We are also typically motivated to have a reference implementation for algorithms that is portable to architectures that may not be supported by highly optimized assembly implementations. However, writing data invariant code in high level languages is difficult due to compiler optimizations. For this reason, having compiler support for a data type that is resistant to timing side channel attacks is desirable.++Timing side channel attacks are a particular threat in a post spectre world [1]. Side channels are primarily used to attack secrets that are+long lived+ - Extremely valuable if compromised+ - Each bit compromised provides incremental value+ - Confidentiality of compromise is desirable+Therefore, it’s important to use data-invariant programming for secrets. For this reason, secret types would only allow data invariant operations at all levels of compilation.++Additionally, secret types serve as an indicator to programmers that this information should be treated with care, and not mixed with non-secret data, an invariant that would be enforced by the type system.++[1] *Cryptographic Software in a Post-Spectre World.* Chandler Carruth. RWC 2020. Recording forthcoming.+++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++Secret integer types are a type of restricted integer primitive. In particular, non-constant time operations like division are prohibited. Printing of secret integers directly is also prohibited--they must first be declassified into non-secret integers.++These integers are intended to form a basis for the creation of other secret types, which can be built on top of them, such as secret strings for storing passwords in them.++Comparison of secret integer types is allowed, but the algorithm is independent of the secrets. Comparison of secret types must return a secret_bool, which cannot be branched on.++Example: comparison+```+let x : secret_i8 = 6;+Let y : secret_i8 = 10;+if (x < y) { // compiler error: cannot branch on secret bool+  ...+}+```+Example: declassification+```+let x : secret_i8 = 6;+let y : secret_i8 = 10;+println!((x ^ y).declassify())+```++Since indexing vectors and arrays is only possible using `usize,` you will be prevented from indexing into a vector or array with a secret integer. Error messages will derive naturally from the type system.+++Secret types will likely be a more advanced topic when teaching Rust.+++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation+For each fixed-size integer type:+Implement the following methods:+- From_be+- From_le+- From_be_bytes+- From_le_bytes+- From_ne_bytes+- Is_positive+- Is_negative+- Leading_zeros+- Min_value+- Max_value+- Overflowing_add+- Overflowing_sub+- Overflowing_mul+- Overflowing_neg+- Overflowing_shl+- Overflowiing_shr+- Overflowing_pow+- Pow+- Reverse_bits+- Rotate_left+- Rotate_right+- Saturating_add+- Saturating_sub+- Saturating_neg+- Saturating_mul+- Saturating_pow+- Signum+- Swap_bytes+- To_be+- To_le+- To_be_bytes+- To_le_bytes+- To_ne_bytes+- Trailing_zeros+- Wrapping_add+- Wrapping_sub+- Wrapping_mul+- Wrapping_neg+- Wrapping_shl+- Wrapping_shr+- Wrapping_pow+++Implement the following traits+Secret integers may only  be combined with other secret integers and the result will be a secret type+- Add+- AddAssign+- BitAnd+- BitAndAssign+- BitOr+- BitOrAssign+- BitXor+- BitXorAssign+- Clone+- Copy+- Default+- Drop+- Mul+- MulAssign

The constant-time behaviour of multiplication can indeed be a problem on some CPUs, although it's very often safe. Much more information is at https://www.bearssl.org/ctmul.html

However, multiplication is extremely useful! Omitting it at one layer likely means that people will simulate it one layer up. (I.e. people will implement multiplication in Rust code using addition etc.) LLVM knows the CPU target, can know the behaviour of mul on that target, and is likely best placed to substitute a constant-time replacement when needed.

avadacatavra

comment created time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 1cc95ac07c17d61bea601832bbdc1f8d13d313db

Define EVP compatibility constants for X448 and Ed448. We do not support these, but Node expects the constants to be there, so define them. Also fill in X25519's OID. Now that we can wrap it in EVP_PKEY, we should have the OID there. (Our serializers don't use the giant OID table, which is why it didn't matter.) Change-Id: Ie0637f0e525c5704a9354c743075c027ace2f631 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39724 Reviewed-by: Adam Langley <agl@google.com>

view details

BoringSSL Robot

commit sha 1c2769383f027befac5b75b6cedd25daf3bf4dcf

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 1cc95ac07c17d61bea601832bbdc1f8d13d313db

Define EVP compatibility constants for X448 and Ed448. We do not support these, but Node expects the constants to be there, so define them. Also fill in X25519's OID. Now that we can wrap it in EVP_PKEY, we should have the OID there. (Our serializers don't use the giant OID table, which is why it didn't matter.) Change-Id: Ie0637f0e525c5704a9354c743075c027ace2f631 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39724 Reviewed-by: Adam Langley <agl@google.com>

view details

push time in a month

PR opened w3c/webauthn

Add “enterprise” attestation type.

In controlled deployments, organisations may wish to tie specific registrations back to individual authenticators. Obviously this has privacy concerns and needs to be gated on local configuration, or special configuration on the authenticator. However, as cloud services are increasingly used, RP IDs are no longer neatly divided into enterprise and consumer contexts, and the RP might not wish to receive the enterprise attestation when used in a consumer context.

This change adds a new level of attestation, “enterprise”, which allows RPs to indicate when they would like to, possibly, receive an attestation that may include uniquely identifying information. This leaves “direct” with its current, less privacy-impacting meaning.

Fixes #1147

+7 -1

0 comment

1 changed file

pr created time in a month

create barnchagl/webauthn

branch : ep

created branch time in a month

issue commentw3c/webauthn

Use of CBOR, and Uint8Array/ArrayBuffer

Issue about considering whether we can help out with CBOR parsing is https://github.com/w3c/webauthn/issues/1363.

craigfrancis

comment created time in a month

issue openedw3c/webauthn

Provide the public key in `AuthenticatorAttestationResponse`

The public key for a freshly created credential is provided inside of the attestation object. However, that is a somewhat complex format that involves decoding CBOR in order to read the public key. If a site doesn't care about attestation (as many won't) we might usefully be able to have browsers provide fields of this structure more directly.

Assumption: absent attestation, web site implementations wouldn't need CBOR if we did this. This appears to be true at first glance since the authenticator data is a fixed-offset binary format (not including extensions).

A reason not to do this would be that it encourages sites to depend on these additional fields, which will only be available in newer browsers. Thus people with older browsers might not be able to use WebAuthn, even though they could if sites put in more work. However, this argument applies to any such ergonomic improvement to the API and so, if we buy it, we're forced to conclude that they're mostly a bad idea as a class.

created time in a month

issue closedw3c/webauthn

Use of CBOR, and Uint8Array/ArrayBuffer

Forgive me for a simplistic question, but why does WebAuthn use CBOR encoding?

This is an API for users to do a single authentication, so there is pretty much no performance benefit of using a binary format, it just makes the API harder for developers to understand, make mistakes, and requires every website to pull in a 3rd party library to parse it (not good for security).

Couldn't this API simply return a JavaScript object, with the values ready to be sent back to the server?

And because the binary data needs to be sent be sent to/from the server, the use of Uint8Array/ArrayBuffer is a pain - can't it use base64 encoding? It's supported in every language, can be easily sent in a POST request, and is used in other fields (e.g. the Client Data challenge is base64 encoded, but the Credential Creation challenge is not).


I started with this ugly mix of PHP and (unsafe-inline) JavaScript to provide the challenge:

<script nonce="<?= htmlentities($script_nonce) ?>" integrity="haha, nope">
    challenge_uInt8 = new Uint8Array([<?= htmlentities(implode(',', unpack('C*', $challenge))) ?>])
</script>

It's much easier/safer to pass a base64 encoded value to JavaScript with a data- attribute:

<input type="button" ... data-challenge="<?= htmlentities(base64_encode($challenge)) ?>" />

Unfortunately I then need to convert this base64 value to something WebAuthn understands:

function base64_to_uint8array(base64) {
    var binary = window.atob(base64),
        array = new Uint8Array(new ArrayBuffer(binary.length));
    for (var k = (binary.length - 1); k >= 0; k--) {
        array[k] = binary.charCodeAt(k);
    }
    return array;
}

var challenge_base64 = this.getAttribute('data-challenge'),
    challenge_uInt8 = base64_to_uint8array(challenge_base64);

And it's worse getting the credentials.create() response into something usable:

var decoder = new TextDecoder('utf-8'),
    clientData = JSON.parse(decoder.decode(result.response.clientDataJSON));

var attestationData = CBOR.decode(result.response.attestationObject); // A whole CBOR parsing library needed for this.

var dataView = new DataView(new ArrayBuffer(2));
var idLenBytes = attestationData.authData.slice(53, 55); // Great, another binary format to parse.

idLenBytes.forEach(function(value, index) {
        dataView.setUint8(index, value)
    });

var credentialIdLength = dataView.getUint16();

var credentialId = attestationData.authData.slice(55, credentialIdLength);
var publicKeyBytes = attestationData.authData.slice(55 + credentialIdLength);
var publicKeyObject1 = CBOR.decode(publicKeyBytes.buffer); // And CBOR is back again.
var publicKeyObject2 = {
        'id': result.id,
        'type': result.type,
        'client_type': client_data.type,
        'client_origin': client_data.origin,
        'client_challenge': client_data.challenge,
        'key_type': publicKeyObject1[1], // 2 = Elliptic Curve; using more magic numbers for keys and values, does this save a few bytes somewhere?
        'key_algorithm': publicKeyObject1[3], // -7 = ECDSA with SHA256
        'key_curve_type': publicKeyObject1[-1], // 1 = P-256
        'key_curve_x': btoa(String.fromCharCode.apply(null, publicKeyObject1[-2])),
        'key_curve_y': btoa(String.fromCharCode.apply(null, publicKeyObject1[-3]))
    };

return JSON.stringify(publicKeyObject2); // Finally, something that can be sent to the server.

As an aside, would the non-JavaScript approach be able to skip most of this extra processing?

closed time in a month

craigfrancis

issue commentw3c/webauthn

Use of CBOR, and Uint8Array/ArrayBuffer

On the call of 2020-01-22 it was decided that the use of ArrayBuffers is reflecting W3C direction as we understand it and that revisiting that would be too much. However, it does appear that implementations that don't care about attestation could be saved from worrying about CBOR if browsers were to parse out the public-key. The group believes that's worth pondering further and we're going to close this issue and open one focused on that.

craigfrancis

comment created time in a month

issue closedw3c/webauthn

Dependence on Browser state for Primary Factor login

I work in the financial industry and username enumeration is not permitted. That means to utilize webauthn for primary factor logins, the browser has to keep a state of whether or not the user has enabled it or not. This can be done via traditional storage mechanisms such as cookies, but I have found those to be fragile and frequently absent.

My concern is that a good portion of the anti-phishing benefit of webauthn for primary factor logins will be lost as a user will still think that a password based login flow is "normal" even though they have enabled webauthn for the primary factor.

For password credentials, the browser both stores and provides a UI for the user to select a credential to send to the server. In Chrome, it's possible to have a login without any HTML UI form elements. I'd propose a similar use case for PublicKeyCredentials. Allow the browser to prompt the user to select a username from the set of public key credentials stored on the device from which to initiate the ceremony. For this to be effective, the selection promise should immediately return with no UI if there are no available credentials (in the same way that navigator.credentials.get({password: true, mediation: 'required'}) behaves).

closed time in a month

ChadKillingsworth

issue commentw3c/webauthn

Dependence on Browser state for Primary Factor login

(This was discussed on the call of 2020-01-22.)

A browser can't be sure whether a 1st-factor flow is suitable for a given website because users might be authenticating with, for example, a USB token that they insert.

In current designs, users register security keys as an additional layer of security and, after that point, they are required for that account to be authenticated, so fallback to passwords alone isn't permitted. (Some sites split the username entry out into a separate step so that they can better guide the authentication based on the exact account that's logging in.)

I get that you would like a button that triggers a WebAuthn login if it'll work, and immediately fails if not. But I don't believe that we can provide that given privacy concerns and given that the platform doesn't know what authenticators a user might insert.

Overall, the decision on the call was that we don't see an action here, I'm afraid.

ChadKillingsworth

comment created time in a month

Pull request review commentw3c/webauthn

Add to sec cons a brief discussion of the sec properties accrued by authnr & client platform proximity

 the wrong [=credential ID=], or if an attacker intercepts and manipulates the [= (a.k.a., [=assertion=]), and thus the interaction would end in an error.  +## Physical Proximity between Client and Authenticator ## {#sctn-client-authenticator-proximity}++In the WebAuthn [=authenticator model=], it is generally assumed that [=roaming authenticators=]+are physically close to and communicate directly with the [=client=].
are physically close to, and communicate directly with, the [=client=].
emlun

comment created time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 48c65b5ca5a8f955ac2037d7c8448747dcc4bbb8

Remove unnecessary win_toolchain cache from non-Windows builders. Change-Id: I094f72133229fdedb5b7be0e2b7585ea011f654f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39704 Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

push eventgoogle/boringssl

David Benjamin

commit sha 1f2eac2f6d75f5734a737a3900bb36b7b2e80789

Remove old LUCI config files. As of https://chrome-internal-review.googlesource.com/c/infradata/config/+/2414772, the CI and CQ should be consuming the new files. Change-Id: I7a2ea44c86b1753336e46a2ad721191a9f09dc36 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39684 Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha a0cdbf989cbd6d0fa6fa13a6d36d3d803447e90d

Allow shared libraries in the external CMake build. It's trivial to add and someone requested it. Although we don't generally take external requests, I suspect that gRPC will ask for it soon enough so worth doing. BUG=309 Change-Id: I59d6b4f8b26841a95ccf09c753e2afc28e13722b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39664 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 3c4529d12a50f0266ba926eaa4967e492f43dab4

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha a0cdbf989cbd6d0fa6fa13a6d36d3d803447e90d

Allow shared libraries in the external CMake build. It's trivial to add and someone requested it. Although we don't generally take external requests, I suspect that gRPC will ask for it soon enough so worth doing. BUG=309 Change-Id: I59d6b4f8b26841a95ccf09c753e2afc28e13722b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39664 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha a965a25952d4e6ed12a9194d3454b69f33f4e99e

Add a few little-endian functions to CBS/CBB. Change-Id: Idf962d587f031c1feed541a43be55dc9a65ca444 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39607 Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha a965a25952d4e6ed12a9194d3454b69f33f4e99e

Add a few little-endian functions to CBS/CBB. Change-Id: Idf962d587f031c1feed541a43be55dc9a65ca444 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39607 Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha b32fbe0e8a2799f9ac8a69dfb97db013f02a869f

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha 89730072b81077cc3e3a973963015b2494d36b1a

Move iOS asm tricks up in external CMake build. This block needs to come before enable_language in order to have the correct effect. Change-Id: I2c0e3332c055828381694305e14f2f54b50bb06b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39644 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

BoringSSL Robot

commit sha 1ef2e8834b845cb47dbdceec6a676722bcf0062b

update master-with-bazel from master branch

view details

push time in a month

push eventgoogle/boringssl

Adam Langley

commit sha 89730072b81077cc3e3a973963015b2494d36b1a

Move iOS asm tricks up in external CMake build. This block needs to come before enable_language in order to have the correct effect. Change-Id: I2c0e3332c055828381694305e14f2f54b50bb06b Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/39644 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>

view details

push time in a month

more