raaz-crypto / raaz Goto Github PK

How should I capture length of message in this case as it will be 2^128. Should I use Integer or 2 Word64?

Write tests to check whether the encodings of little and big endians are reverse of each other.

Although it is mentioned in the documentation but no default instance of iterateHash given.

I forgot to make the above change. Either you can change this or I will create a commit for the same.

There are two kinds of hmac tests that we can add

1. A quick check test where a direct implementation of hmac on bytestrings is compared with the one defined in Raaz.MAC
2. Unit tests.

I have implemented some part of the AES standard. I am not sure how to implement multiplication in GF.

Code can be seen at here

There are three different loads in the raaz library.

1. The Haskell variants (for Word32LE/Word32LE and Word64LE/Word64BE)
2. The portable C variants
3. The platform specific C variants (provided by gcc)

It would be good to see benchmarks on these.

why load ptr is not giving same result as peek ((castPtr ptr) :: Ptr a)?

The CryptoCell and CryptoArray should be using peek and poke instead of load and store. That means the constraint on them should be Storable a instead of CryptoStore a. The load and store as we discussed before is only relevant in serialisation/deserialisation to the outside world. In memory stuff should be stored in the normal way.

We would like to have generic functions that help auto tune Hash instances.

I was trying to implement sha256 cportable version and ended into naming conflicts

/usr/bin/gcc returned ExitFailure 1 with error message:
In file included from /tmp/19611.c:2:0:
cbits/raaz/hash/sha256/portable.h:26:14: error: conflicting types for ‘Hash’
typedef Word Hash [ HASH_SIZE ];
^
In file included from /tmp/19611.c:1:0:
cbits/raaz/hash/sha1/portable.h:26:14: note: previous declaration of ‘Hash’
was here
typedef Word Hash [ HASH_SIZE ];
^
cabal: Bad header file: raaz/hash/sha256/portable.h

We should change the naming to be more specific to the hash it is implementing.

Suppose I entered my password in a secure bytestring using getPass. How do I hash this securely without copying my password to a separate buffer? Because padding needs extra bits, I can not work on foreignPtr of the ByteString directly.

The travis builds are failing despite the fact that the build on the local machines work fine. The reason for the failure is that they only do a shallow copy of the repository and hence checkout the other branches are failing. The makefile is doing a checkout to other patches. We might have to merge the patches on primitive and build the other branches appropriately.

Needed for hash functions in RSA. Like maximum bytes that can be processed bu SHA1 = 2^61 - 1.

The library should support the following usecases

(1) There should be a straight forward way to perform a crypto primitive that uses the autotuned implementation

(2) There should be a way to call a specific implementation of a crypto primitive.

The use case (2) is required to support for example benchmarking different implementation and also to avoid use of certain hardware (for example on a desktop one might want to spare the graphics card for actual graphics operation than crypto operations, which requires avoiding implementations like CUDA for example)

https://github.com/satvikc/raaz/blob/x-primitives/raaz-primitives/tests/Modules/ByteString.hs

I have written some tests which compile correctly but give segmentation fault on running. I am not able to find out the cause of error.

While installing raaz-primitives cabal fails to run the configure script. This seems to be a cabal bug as directly configuring and building from the Setup.lhs seems to be working. Need to think of a workaround.

I also don't like this external configure script. It would be good if we create an appropriate hook without relying on the autoconfHook. But cabal documentation on Hooks look scary and has a lot of bewares

Instead of them taking BYTES Int as argument, make them take any length type that are crypto-coerceble to BYTES Int. This can avoind some cryptoCoerce calls by the callee

Start a mailing list to take care of announcements and other discussions.

It would be desirable to have a unit testing function that tests the hashes value against know strings. A function like the one below would be good.

standardHashValues :: ( Hash h , HashImplementation i h) =>  i -> h -> [ (ByteString, ByteString) ] -> Test

The bytestring pairs denote tuples of input to the hash function and their corresponding hash value (in hexadecimal).

See

https://github.com/hvr/multi-ghc-travis

I have added a non TH implementation of SHA1 at https://github.com/satvikc/raaz/blob/x-sha-ref/raaz-hash-sha/Raaz/Hash/Sha/Sha1/Ref/Sha1Ref.hs

and it shows ~10% improvement in performance.

keccak is the winner of the sha3 contest see http://keccak.noekeon.org/. Besides other things
this implementation will consolidate the Hash interface

A high-level design for memory locking is given below. I am just mentioning types for brevity.

allocMem :: Size -> StateT Store IO CryptoPtr
freeMem :: CryptoPtr -> Size -> StateT Store IO ()
lockMem :: CryptoPtr -> StateT Store IO Bool
unlockMem :: CryptoPtr -> StateT Store IO Bool

class Monad m => Memory a m where
  newMemory :: m a
  freeMemory :: a -> m ()
  withMemory :: (a -> m b) -> m b

class (Monad m, Memory a m) => Lockable a m where
  secureMemory :: a -> m Bool
  unsecureMemory :: a -> m Bool
  withSecureMemory :: (a -> m b) -> m b

instance Memory CryptoCell IO 

instance Memory CryptoCell (StateT Store IO)

instance Lockable CryptoCell (StateT Store IO)

A problem with the approach is nothing restricts user from using newMemory and secureMemory in different monads. For example, user can use CryptoCell returned from newMemory :: IO CryptoCell inside secureMemory.

http://csrc.nist.gov/groups/ST/toolkit/examples.html#aHashing

The following needs to be done to the raaz-tests package.

1. The tests prop_LengthDivisibility and prop_padLength can be extend to any instance
   of HasPadding.
2. Have a quick check test that tests the reference implementation with a given implementation
3. Have standard tests only for the reference implementation.

The length function of Data.ByteString just returns an Int. Not a very good choice for type safe length
manipulations.

I started writing some parts of sha-256 and found the most of the instance declarations are mechanized repetition of what we did for sha-1. So it would we nice if we can automate the instance generation process for these.

I have added the gadget class and refactored memory and SecureMemory.

• I have moved from Using the state monad to just a function which takes BookKeeper as the argument. It was not possible to compose memory instances if we were using state monad.
• Also I have moved from mmap to posix_memalign and wrote tests to detect if it is available. The code is portable in the sense that it sets and checks necessary flags.
• MAC and Hash are broken because of the new gadget interface.

Here is the link https://github.com/satvikc/raaz/tree/x-memory/raaz-primitives/Raaz

Helper functions, on the lines of hashByteString, for hashing a file.

hashFile :: (Hash h, HashImplementation i h) => i -> FilePath ->  IO h
hashHandle :: (Hash h, HashImplementation i h) => i -> Handle -> IO h

It would be a good idea to move out the tests to a separate package. That would mean that an end user who does not care about the tests can safely ignore those dependencies (testframework, quickcheck, hunit) etc. I suggest the following:

1. Create a raaz-tests package which will contain
   • tests for types in raaz-primitives
   • All the generic tests that raaz-primitives expose via the module Raaz.Test modules.
2. Get rid of all the generic tests exposed by some module Raaz.Test.Foo module from raaz-primitives
3. The testsuits of other packages that currently use the generic tests from raaz-primitives, instead
   depend on raaz-tests

Of course raaz-tests will have to depend on raaz-primitives

I asked this on SO and @don said that TH is the way to do this. I am working on this but this will require writing lots of TH code so it might take some time. After I am done we will be able to do something like

 $(unroll 0 5 [d| fibonacci i | i < 2 = 1 
                              | otherwise = fibonacci (i-1) + fibonacci (i-2) |])

and this will generate variables like

    f_0 = 1
    f_1 = 1
    f_2 = f_0 + f_1 
    f_3 = f_1 + f_2
    f_4 = f_2 + f_3
    f_5 = f_3 + f_4

For loop you might look at http://www.haskell.org/pipermail/haskell-cafe/2009-February/056248.html

Currently raaz-executable provides the sha1sum program to compute the sha1sum of files. Rename it to raaz-checksum and generalise it to compute all the supported hash (the hash algorithm being selected by command line options). We should support the following features

The command line options should have

1. version and help message
2. hash algorithm selection
3. hash verification (like sha1sum)
4. support the text as well as binary format.

This is the first step towards a working ssh client library. This will also be a testbed for the API we have charted out in the primitives library. It will clarify some of the type classes and associated types.

Currently we have a package for all sha family hashes. The idea was to keep a minimal
core i.e. hashes that are more or less standard. Therefore hashes that are not in the SHA family will have to be implemented in a separate package.

While justified in a way, I think it might be better to have all hash related stuff in one package called raaz-hash. It could mean the following rearrangement of modules.

Apart from the raaz-hash-sha package being renamed to raaz-hash, we can reorganize such that Raaz.Primitives.Hash from raaz-primitives,
Raaz.Hash.Test from the raaz-tests and Raaz.Hash package can now move
to the new raaz-hash package.

Currently there are no tests that cover the members iterateHash and processHash functions. Write tests for them as well

There should be a module say Raaz.System.Parameters that export the system dependent parameters (for example L1/L2 cache size) of interest to the other raaz packages. The best
way to do this would be to generate a c header file (through some preconfiguration hooks) and
include it (using hsc).

Add a function in the HashGadget typeclass which gives the DER encoded hash value. Needed in RSA.

There should be function in Hash class which can convert the given hash to say its hexadecimal bytestring. It is required in the testing part as hashByteString returns a Hash and not a ByteString

toByteString :: h -> ByteString 

Also allHashTests should take a implementation too or we would need a allHashImplementationTests function separately to test implementations.

I have added the generalised subscripting code in Raaz.Util.TH module of raaz-primitive. However,
it is breaking the code in the raaz-hash-sha package. It has got to do with some typing issues.

It would be good to support travis (See https://travis-ci.org/)

Have a new package raaz which exports every thing.

1. current Raaz.Hash should move to Raaz.Primitives.Hash
2. The module Raaz.Hash in raaz packages expose all the hashes (but without their constructurtors)
3. The actual constructors are avialable at Raaz.Hash.Sha1 etc.

It was expected that template haskell based unrolling of computations in the reference implementations can lead to speed up unachievable by other means like inlining. It seems this is not true. I would therefore propose getting rid of all template haskell code.

The disadvantages of TH code is that the resulting implementations are not any more readable. Besides the stage restrictions and the inability to document (haddock) is a serious limitation.

Arch has updated ghc to ghc 7.6 stable version. Change of dependencies like base is updated to 4.6.0.0.

http://hackage.haskell.org/package/tagged-0.2.3.1

This is used to output decent messages while benchmarking and testing. Currently I am taking an extra string for the message.

Some of the coersion we allow are not safe due to rounding errors. For example

1. BITS to BYTES
2. BYTES Word64 to BYTES Word32
3. BLOCKS to BYTES or BITS.

We can disallows such instances. I noticed that we have used CryptoCoerce when
we want to round of things. Although the uses are correct it might be a better idea to have ad different Round class for these conversion and use CryptoCoerce only when there is no loss of information.

In the definition of ffiTest you used "haskell-compiler" for compiling. Where is that defined? As it is not defined by default on my system and hence the tests fail.