jj5 / kickass-crypto Goto Github PK

Consider providing a list of books and other reading that programmers using crypto might be interested in.

The doc comments in the source code (the docblocks) should be reviewed for consistency and completeness.

Over here we need to update the catch handler to ignore exceptions from ignore().

Put "Comments? Questions? Suggestions?" under the heading Feedback.

Point out in the recursion demo code the "infinite loop" isn't actually an infinite loop because PHP doesn't implement tail recursion.

Can I kick it?

Keep an eye on call depths and report on their maximum values in the telemetry data. Maybe make sure enter() and leave() are counted too.

Add a link in the colophon to: https://dwheeler.com/sloccount/

get_error_list() should not throw; make it return [ 'broken get_error_list()' ] or something instead.

Similarly get_error() should not return null if it's broken; return 'broken get_error()' instead.

If clear_error() is broken register a new error 'broken clear_error()`.

Basically anything on the public interface should register an error if something goes wrong.

At the moment there are a bunch of error conditions which are untested. So find those and test them. Resolve issue #3 prior to working on this issue.

Consider introducing an auto-generated table of contents for README.md, and putting the synopsis under a heading too.

There are a lot of stubs in the KickassCrypto base class for errors which are nominated as 'TODO: model this error'. Those should all be replaced with constant values appropriate to the error.

You will find some code like this:

      assert( is_string( $result ) || $result === false );

      if ( is_string( $result ) || $result === false ) {

        return $result;

      }

      return $this->error( __FUNCTION__, KICKASS_CRYPTO_ERROR_RESULT_INVALID );

The problem is we can't test the error case because the assertion blows up. So remove all such assertions.

The info about data encoding in the README.md file was written when the only supported data encoding was JSON; but now we have PHP serialization and plain text options, and those should be documented.

Default to null and if null use the encoding from the config file.

Tidy up the following notes and put them in the README.md.

A crypto service implements IKickassCrypto. There are four types of crypto service provided by this library, and implementers can define their own.

The crypto framework is a base class KickassCrypto which implements the IKickassCrypto interface; some parts of KickassCrypto are abstract and must be provided by implementations.

A use case suggests approaches to the number and types of secret keys that are used, implementers can add use cases; the two default use cases are:

• round-trip
• at-rest

A service locator finds a service for a particular use case, the library includes two service locators, one for each use case; the two default service locators are:

• kickass_round_trip()
• kickass_at_rest()

A module provides a crypto service for each use case, so by default that's two services per module, one for each use case.

This library provides two modules, Sodium and OpenSSL; as each module provides two services the full list of complete services supported by this library is:

• KickassSodiumRoundTrip
• KickassSodiumAtRest
• KickassOpenSslRoundTrip
• KickassOpenSslAtRest

Services for use cases within modules are designed to be independent because they use different secret keys; however if the services within a module did share secret keys then they should be mutually compatible. That is, if you configured the round-trip and at-rest secret keys to be the same, then any service in a module could be used to encrypt or decrypt any given plaintext or ciphertext. So the only thing that keeps services within a module independent should be the secret keys, otherwise services within a module should be mutually compatible.

Add a reference to the CONTRIBUTORS.md file
here.