Paul Yang c1da4b2afe Add poly1305 MAC support
This is based on the latest EVP MAC interface introduced in PR #7393.

Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7459)
2018-11-05 13:07:07 +08:00
..
2018-05-23 11:12:13 -04:00
2018-11-05 13:07:07 +08:00
2018-09-11 13:45:17 +01:00
2018-02-27 13:59:42 +00:00
2018-09-11 13:45:17 +01:00
2018-05-29 13:16:04 +01:00
2017-12-07 19:11:49 -05:00
2017-08-25 11:34:08 +01:00
2018-05-08 08:43:39 +01:00
2018-07-11 09:03:22 +10:00
2018-02-27 13:59:42 +00:00
2017-11-13 07:52:35 -05:00
2018-09-13 09:00:29 +01:00
2018-03-20 13:08:46 +00:00
2018-09-10 10:32:33 +01:00
2017-08-22 09:54:20 -04:00
2018-05-29 13:16:04 +01:00
2018-05-29 13:16:04 +01:00
2018-10-10 09:40:01 +01:00
2018-09-11 13:45:17 +01:00
2018-11-05 08:09:41 +10:00
2018-05-29 13:16:04 +01:00
2017-08-22 09:54:20 -04:00
2018-03-20 13:08:46 +00:00
2018-05-29 13:16:04 +01:00
2018-07-13 18:14:43 +01:00
2018-03-20 13:08:46 +00:00
2017-08-22 09:54:20 -04:00
2018-05-29 13:16:04 +01:00
2018-03-20 13:08:46 +00:00
2018-09-11 13:45:17 +01:00
2018-05-29 13:16:04 +01:00
2018-05-29 13:16:04 +01:00
2018-02-13 13:59:25 +00:00
2017-08-22 09:54:20 -04:00
2017-08-22 09:54:20 -04:00
2017-08-22 09:54:20 -04:00
2017-09-08 13:58:59 -05:00
2018-03-20 13:08:46 +00:00
2018-10-23 08:01:48 +10:00
2018-05-01 13:34:30 +01:00
2018-09-11 13:45:17 +01:00
2018-09-11 13:45:17 +01:00
2018-03-20 13:08:46 +00:00
2018-10-30 12:08:42 +00:00
2018-03-20 13:08:46 +00:00
2018-03-20 13:08:46 +00:00
2018-08-07 10:51:01 +10:00
2018-05-29 13:16:04 +01:00
2018-05-01 13:34:30 +01:00
2018-05-29 13:16:04 +01:00
2018-06-20 15:29:23 +01:00

How to add recipes
==================

For any test that you want to perform, you write a script located in
test/recipes/, named {nn}-test_{name}.t, where {nn} is a two digit number and
{name} is a unique name of your choice.

Please note that if a test involves a new testing executable, you will need to
do some additions in test/Makefile.  More on this later.


Naming conventions
=================

A test executable is named test/{name}test.c

A test recipe is named test/recipes/{nn}-test_{name}.t, where {nn} is a two
digit number and {name} is a unique name of your choice.

The number {nn} is (somewhat loosely) grouped as follows:

00-04  sanity, internal and essential API tests
05-09  individual symmetric cipher algorithms
10-14  math (bignum)
15-19  individual asymmetric cipher algorithms
20-24  openssl commands (some otherwise not tested)
25-29  certificate forms, generation and verification
30-35  engine and evp
60-79  APIs
   70  PACKET layer
80-89  "larger" protocols (CA, CMS, OCSP, SSL, TSA)
90-98  misc
99     most time consuming tests [such as test_fuzz]


A recipe that just runs a test executable
=========================================

A script that just runs a program looks like this:

    #! /usr/bin/perl

    use OpenSSL::Test::Simple;

    simple_test("test_{name}", "{name}test", "{name}");

{name} is the unique name you have chosen for your test.

The second argument to `simple_test' is the test executable, and `simple_test'
expects it to be located in test/

For documentation on OpenSSL::Test::Simple, do
`perldoc util/perl/OpenSSL/Test/Simple.pm'.


A recipe that runs a more complex test
======================================

For more complex tests, you will need to read up on Test::More and
OpenSSL::Test.  Test::More is normally preinstalled, do `man Test::More' for
documentation.  For OpenSSL::Test, do `perldoc util/perl/OpenSSL/Test.pm'.

A script to start from could be this:

    #! /usr/bin/perl

    use strict;
    use warnings;
    use OpenSSL::Test;

    setup("test_{name}");

    plan tests => 2;                # The number of tests being performed

    ok(test1, "test1");
    ok(test2, "test1");

    sub test1
    {
        # test feature 1
    }

    sub test2
    {
        # test feature 2
    }


Changes to test/build.info
==========================

Whenever a new test involves a new test executable you need to do the
following (at all times, replace {NAME} and {name} with the name of your
test):

* add {name} to the list of programs under PROGRAMS_NO_INST

* create a three line description of how to build the test, you will have
to modify the include paths and source files if you don't want to use the
basic test framework:

    SOURCE[{name}]={name}.c
    INCLUDE[{name}]=.. ../include
    DEPEND[{name}]=../libcrypto libtestutil.a

Generic form of C test executables
==================================

    #include "testutil.h"

    static int my_test(void)
    {
        int testresult = 0;                 /* Assume the test will fail    */
        int observed;

        observed = function();              /* Call the code under test     */
        if (!TEST_int_equal(observed, 2))   /* Check the result is correct  */
            goto end;                       /* Exit on failure - optional   */

        testresult = 1;                     /* Mark the test case a success */
    end:
        cleanup();                          /* Any cleanup you require      */
        return testresult;
    }

    int setup_tests(void)
    {
        ADD_TEST(my_test);                  /* Add each test separately     */
        return 1;                           /* Indicate success             */
    }

You should use the TEST_xxx macros provided by testutil.h to test all failure
conditions.  These macros produce an error message in a standard format if the
condition is not met (and nothing if the condition is met).  Additional
information can be presented with the TEST_info macro that takes a printf
format string and arguments.  TEST_error is useful for complicated conditions,
it also takes a printf format string and argument.  In all cases the TEST_xxx
macros are guaranteed to evaluate their arguments exactly once.  This means
that expressions with side effects are allowed as parameters.  Thus,

    if (!TEST_ptr(ptr = OPENSSL_malloc(..)))

works fine and can be used in place of:

    ptr = OPENSSL_malloc(..);
    if (!TEST_ptr(ptr))

The former produces a more meaningful message on failure than the latter.