General Discussion - haskell - crypto platform - basics

[workoblue workblue]

Congratulations.

The roadmap and the goals and the mission is: ???

Please note: IMHO, not expert, mileage will vary, other disclaimers

One benchmark I use is 'latest Linux Kernel' vs. FreeBSD vs. other

Framework:

    scenario based development

    .character based development -  all the way to GHC

      behavior driven devel - BDD

      test driven devel TDD

       code

test case from kernel code: CVE Vulnerability exploit OpenBSD

https://banu.com/blog/42/openbsd-bug-in-the-random-function/

note: not an endorsement, can be beyond my deep understanding

"algorithm: random.c

////////////////////////////////////////

lessons learned from TrueCrypt

make and build process must be STRONG and DETERMINISTIC

this may be too advanced (for me perhaps)

Neil Mitchell - Shake - Haskell Community Server

http://community.haskell.org/~ndm/shake/

suggest:  what are your thoughts?

1.)LLVM and clang toolsets

2.)other toolsets  -- ?

3.)GHC process, lint, other

4.)Quickcheck and beyond

5.)Rosetta code comparison with python and even C++

6.)...

wish list

FreeBSD with latest toolset

Strong (no race conditions)  make via haskell shake.

Trusted Chain all the way to hardware

avoiding the 'fake crypto hardware'???

the reason for haskell is flexibility and customization

practical meaning common use scenarios

elliptic curve, but this could be 'too complex'

[Vincent Hanquez]

Hi, i need to write some roadmap & goals somewhere, but roughly it's to provide a good cryptographic and cryptographic-related set of libraries for Haskell. One of the side goals is to organize some individuals efforts into something a bit more common.

Related to build environment, I'm not we need more guarantees than providing the source with correct cabal files.

Although i would really like to have a shake file to build all the platform in one go

There's not much process at the moment, although one thing that I like to have is

quickcheck tests. Everything is open in the air, but the starting point would be

to have discussion about specific area and write some documents following agreements.

Basic elliptic curve crypto is coming soon. The security part is unknown at the moment,

but in time we'll review it and hopefully improve it too.

[Danny Navarro]

I've seen the `cipher` packages have undergone major changes recently, whereas the `pubkey` packages have stayed as they were.

Having in mind ECC, I suspect that reaching acceptable performance and security using Integers will be tricky. I like the approach taken with the datatypes in `cipher-aes`, for example (I assume the other `cipher` packages follow similar structure). Using similar data types in ECC will be more work, but at least, I think, it'll be possible to have more control over what it's the code exactly doing.

Can we consider `cipher-aes` as a reference implementation for a *modern* crypto package? Is it a goal to have the `pubkey` packages follow the structure of the `cipher` packages?

--
You received this message because you are subscribed to the Google Groups "haskell-crypto-platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-crypto-pl...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Vincent Hanquez]

On Wednesday, October 30, 2013 4:59:11 PM UTC+8, Danny Navarro wrote:

I've seen the `cipher` packages have undergone major changes recently, whereas the `pubkey` packages have stayed as they were.
 

Having in mind ECC, I suspect that reaching acceptable performance and security using Integers will be tricky. I like the approach taken with the datatypes in `cipher-aes`, for example (I assume the other `cipher` packages follow similar structure). Using similar data types in ECC will be more work, but at least, I think, it'll be possible to have more control over what it's the code exactly doing.

Can we consider `cipher-aes` as a reference implementation for a *modern* crypto package? Is it a goal to have the `pubkey` packages follow the structure of the `cipher` packages?

 

(I'm assuming you're talking about splitting package in smaller chunks here)

I'm open to this outcome, but pubkey is slightly different than symettric ciphers:

* there's many less useful public key scheme compared to symmetric cipher: having a more split approach, make it more possible to have more people maintain their own ciphers.

  public key algorithms are far fewer and they all have similarities (e.g. ElGamal, DH, DSA are all derivative of the same discrete log problem)

* it's a bit of a pain to work with splitted packages: in a perfect world I would prefer each functionality to have its own package, but it create lots of problems and considering the algorithm similarities, I think it's OK to have this layout.

Regarding integer, and security/performance:

I agree. I think it's impossible with the current API and exposed features to reach parity with proper implementations of public key algs. I've started a mutable big number haskell library but it's not even able to add number yet, and I don't really have time to work on it much. There's some light though, as Herbert recently made available more primitives from GMP, including fast modular exponentiation, secure modular exponentiation, fast gcde. Maybe it's possible to identity the slowest primitive in ECC and have either some more primitive or some composite code to handle what we need.

For ECC, you mentions some types that would help you, could you be more specific ? It would be nice FTR to have a list.

-- 

Vincent

[Danny Navarro]

On Sun, Nov 3, 2013 at 3:41 AM, Vincent Hanquez
<vincent...@gmail.com> wrote:
>
>
>
> On Wednesday, October 30, 2013 4:59:11 PM UTC+8, Danny Navarro wrote:
>>
>> I've seen the `cipher` packages have undergone major changes recently, whereas the `pubkey` packages have stayed as they were.
>>
>>
>> Having in mind ECC, I suspect that reaching acceptable performance and security using Integers will be tricky. I like the approach taken with the datatypes in `cipher-aes`, for example (I assume the other `cipher` packages follow similar structure). Using similar data types in ECC will be more work, but at least, I think, it'll be possible to have more control over what it's the code exactly doing.
>>
>> Can we consider `cipher-aes` as a reference implementation for a *modern* crypto package? Is it a goal to have the `pubkey` packages follow the structure of the `cipher` packages?
>
>
> (I'm assuming you're talking about splitting package in smaller chunks here)
>
> I'm open to this outcome, but pubkey is slightly different than symettric ciphers:
>
> * there's many less useful public key scheme compared to symmetric cipher: having a more split approach, make it more possible to have more people maintain their own ciphers.
> public key algorithms are far fewer and they all have similarities (e.g. ElGamal, DH, DSA are all derivative of the same discrete log problem)
> * it's a bit of a pain to work with splitted packages: in a perfect world I would prefer each functionality to have its own package, but it create lots of problems and considering the algorithm similarities, I think it's OK to have this layout.

I wanted to know more about splitting the pubkey package because if it
was one of the future goals, then it might have been better to take
care of it now. Having a single package for public key crypto is fine
with me.

>
>
> Regarding integer, and security/performance:
>
> I agree. I think it's impossible with the current API and exposed features to reach parity with proper implementations of public key algs. I've started a mutable big number haskell library but it's not even able to add number yet, and I don't really have time to work on it much. There's some light though, as Herbert recently made available more primitives from GMP, including fast modular exponentiation, secure modular exponentiation, fast gcde. Maybe it's possible to identity the slowest primitive in ECC and have either some more primitive or some composite code to handle what we need.
>
> For ECC, you mentions some types that would help you, could you be more specific ? It would be nice FTR to have a list.

I didn't know about the recent developments in GMP API, those are
great news, I'll have a look at the new API.

Compared to RSA, ECDSA signing/verifying is quite slow. I didn't
profile at ECDSA level but performance should be bound to ECC point
multiplication. When profiling the arithmetic operations over F2m I
remember that inversion performance was OK and reduction was the
limiting step for multiplication, which with the proper algorithm it
shouldn't be. I was also expecting squaring to be much faster than
multiplying 2 equal numbers (it's just intercalating '0's in between
every digit in binary representation) but with my naive implementation
is way slower. Also, there is some overhead computing the bit length
(log2), if the length was fixed it shouldn't be needed. But I don't
know much about bit bashing, there might be some clever tricks to not
depend on bit length so much and to do the squaring much faster, but I
don't know if it's even possible with GMP. However, before trying to
optimize the current implementation, I think it's important to change
the algorithms to get secure point multiplication. I'll give a try to
the new GMP API for that.

I didn't profile the primitives over Fp, the bottlenecks could be very
different from F2m, that's something that needs to be done, too.

BTW, I have some dummy executables for profiling F2m primitives which
I didn't check them in because I use clunky shell parameters to get
the results. Do you know any Haskell package I can look up in order to
organize and automatically run the profiling scripts? Does criterion
provide something to identify bottlenecks?

There is also the question of hardware acceleration. For example, it
should be possible to take advantage of PCLMULQDQ in AES-NI, for
multiplication over F2m. Does GMP use hardware acceleration
automatically? How to make sure it's kicking in when using the Haskell
GMP API?

>
>
> --
> Vincent