Você não pode selecionar mais de 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.
 
 
Henry D. Case 0f494ae8f1 Initial commit 6 anos atrás
bssl Initial commit 6 anos atrás
mbedtls Initial commit 6 anos atrás
testapp Initial commit 6 anos atrás
.gitmodules Initial commit 6 anos atrás
APPENDIX.md Initial commit 6 anos atrás
README.md Initial commit 6 anos atrás
common.mk Initial commit 6 anos atrás

README.md

Test app

It’s a implementation of simple C-based test application, which compiles and links against library under test and run on ARMv8 platform running Android operating system. The app is composed of client and server. As we are only interested in client side of the TLS end, we fix the server to always use same library (it’s based on BoringSSL). Server is configured to support only TLSv1.2 (as 1.3 is not supported by mbedTLS, yet [OZAPTF]). It’s always run with an argument which specifies cetificate type to be used (RSA, ECDSA or EdDSA based). Once run it always enforces same cipher suite to be used - for example in case of RSA it will be ECDHE key agreement with RSA signature and AES/256 in GCM AEAD mode.

Client application is the one which we want to benchmark. We have implemented one which uses mbedTLS API and links with this library and similar one for BoringSSL. Client always establishes TCP connection in blocking mode (simplicity). It implements 3 different tests:

  • Handshake : during this test client opens TCP connection and performs many handshake without closing the connection. Performance of this test highly depends on key type used for certificate signing and symmetric key agreement algorithm (as well as elliptic curve used), hence this test is performed multiple times, once for each certificate type
  • Write: clients opens TCP connection and sends few hundred megabytes of data. This test is done mostly to assess performance of symmetric encryption
  • Read: clients opens TCP connection and sends a request to the server which sends back few hundred megabytes of data. This test is done mostly to assess performance of symmetric decryption

Compilation

In order to compile an app one needs to have Android NDK already installed. After cloning, location of the NDK needs be specified in common.mk. Then, execute following commands in the app directory.

git submodule init
git submodule update

cd bssl; make -f Makefile.aarch64
cd mbedtls; make -f Makefile.aarch64
cd testapp; make -f Makefile.aarch64

Output of an execution is set of binaries for ARMv8 that run on Android:

  • BoringSSL
  • MbedTLS
  • Testing application
    • server: BoringSSL based test server
    • b_client: BoringSSL based client
    • m_client: mbedTLS based client

Pushing tests to target

Execute following target to push needed binaries and all needed files (certificates):

cd testapp; make -f Makefile.aarch64 push

Server

Tests always use BoringSSL-based server. Following command will start server which will accept only ECDSA certificate. Server always supports only 1 cipher suite (for example - in case of RSA it supports only TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ). It’s done deliberatelly in order to make sure that when client connects to serwer it always uses same cipher, so that comparision between different clients is accurate.

./server ECDSA_256

Client

There are two clients called m_client and b_client, respectively, mbedTLS-based and BoringSSL-based. Client application connects to the server app and initiates a test. Once test is over, both client and server will exit. Client application can be started in following way:

Example of mbedTLS test execution:

./m_client test_Handshake

Example of BoringSSL test execution:

./b_client test_Handshake

The structure of both clients is being kept as similar as possible.