>1. We need spec/test for krypt itself (Ruby) that implements krypt API using krypt-core API, and spec for krypt-core API which is implemented in C and Java. And we're searching the best location for the latter, spec for krypt-core API. Am I understanding correctly? Then yes, krypt can be a place for the spec for krypt-core API. I think we should split krypt-core API spec from krypt API's one, such as spec/krypt and spec/krypt-core, then we can easily refer krypt-core API spec from krypt-core (C) and krypt-core-jruby. And spec/krypt-core/asn1 would be one of a source of deliberative for the grant. Can reorganize spec dir of krypt?

Yes, that makes perfect sense. I'm all for it!

> 2. For krypt-core-jruby, I'll wait your work. After I give a try to create C-ext coverage build harness, I'll try to improve spec coverage of krypt-core and krypt-core-jruby. (https://github.com/emboss/krypt-core/commit/9c1565bc3b78536e4c9889fa2ea4f566e0e925eb)

> 3. I'll give this one-day try first.

Awesome, thank you! You had a question mark for the return value type of Header#value_io. I added a comment: https://github.com/emboss/krypt-core/commit/9c1565bc3b78536e4c9889fa2ea4f566e0e925eb#commitcomment-872677.

BTW, what do you think of the Parser, Header and Asn.1 interface so far? I tried to stick close to OpenSSL::ASN1 with Krypt::Asn1 except for the fact that I intentionally left out the "tagging" attribute for now. It was only meant as convenience for encoding, but it is not strictly mandatory. We could still add it later, but I'm not entirely convinced yet because it will stay nil for all parsed values. I also thought it's less important than in OpenSSL::Asn1, because with krypt, you would typically encode Asn1 data using the template mechanism, which already handles explicit/implicit tagging. I don't know, what do you think?

>For bm directory, I'll try it today. I think the krypt-core related resources is better fit for krypt-core repo, and make krypt-core-jruby just refer it at this moment. krypt -> krypt-core -> {krypt-core-c,krypt-core-java} is what's their ideal hierarchy, and you decided to call krypt-core + krypt-core-c as 'krypt-core', I thought.

OK, I see the point in this hierarchy. The only problem is if we would make krypt-core an abstract entity whose manifestations are krypt-core-c and krypt-core-java/jruby, then I wouldn't know what to call the part that I currently call krypt-core-C. It's the part that bridges crypto primitives implemented by third-party native libraries (OpenSSL, JCE etc) to a common native interface, like you mentioned in your last comment. I would tend to think we could just integrate them within the current krypt-core and krypt-core-jruby, but I would prefer to make the "bridge" part an entity of its own, so that users that would like to replace the "bridge part" could simply compile a bridge gem of their choice that implements our native interface without having to deal with actual krypt-core/krypt-core-jruby code.
But with your view in mind I am now convinced, too, that we should probably revise the hierarchy a bit. What do you think of:

                                  krypt
                                 /       \
                  krypt-core-c      krypt-core-java       (On an abstract level, both are implementations of "krypt-core")
                           |                         |
                  krypt-bridge-c    krypt-bridge-java    (Again, both are impls of an abstract "krypt-bridge")

What we could do then is specify the bridge API already in krypt-core-c and krypt-core-java:

For krypt-core-c, one way I could imagine is to specify an API in a header file using "extern", much like PKCS#11 does it:
Have a header krypt-bridge.h which specifies for example:

struct krypt_rsa_st; //Anonymous forward decl to ensure maximum degree of freedom in implementation
typedef struct krypt_rsa_st krypt_rsa;
extern long krypt_bridge_digest_sha1(unsigned char* msg, long msg_len, unsigned char **out);
extern krypt_rsa *krypt_rsa_new(void);
...

This header would be included by krypt-core.h and we would have to ensure while building krypt-core-c that it is linked to a library that provides these functions defined in krypt-bridge.h. By default it would link against the OpenSSL implementation which would be available as a separate gem. We could then also offer the option that users could provide a different gem that would provide the krypt-bridge implementation. I'm not sure, is this technically possible for gems? It should be IIRC, it's similar to what DataMapper does?

For Java things are easier, we would add krypt-bridge Interfaces to krypt-core-java:

public interface Digest {
    public byte[] digest(byte[] msg) throws KryptDigestException;
}

and so on. To create instances we could take several routes:

- Offer factory classes that create instances using Class#forName. We could either specify that a Jar implementing krypt-bridge needs to put a dedicated Properties file in its root directory mapping implementation class names to interfaces, which is how we would obtain the appropriate class names.
- Use a Registry approach like JCE does (Security#addProvider)
Which would you prefer? 

The advantage of splitting krypt-core and krypt-bridge into two separate entities would be that in order to switch let's say from OpenSSL to MS-CAPI or from JCE to Bouncy Castle all you have to do is implement a minimal set of functions and link the krypt-core library with your new implementation opposed to having to rebuild the whole thing from scratch, possible copying lots of boilerplate code that shouldn't be touched, like the Asn1 or Template code.

At least that's the picture in my imagination, would you agree with this revised hierarchy? If so, where would you do things differently? Or did you have something completely different in mind?

But if you do agree with this new structure, I would create the bridge repos (please come up with a better name :) and rename the existing "krypt-core" repos.

>Re: plan, do you have a work item for this? "- parts of the implementation of the rest of the cryptographic primitives (these will simply wrap existing functionality comprised in native libraries - OpenSSL for the C part (krypt-core-C) and JCE for Java)" I can help this if you like, I think.

Actually, I don't. What should we use? Is GitHub Issues sufficient, or should we use some other service? At work, we use FogBugz or JIRA, but personally, I prefer Kanban style systems. I'm all open to your suggestions there, whatever you prefer! I agree we should have this, much easier to not step on each other's toes that way :P

And again, thanks for your help. It's a real pleasure working with you, I learned and still do learn so much, thank you!