Re: Sharing my 256-bit ECC library

On Jun 14, 4:58 pm, CatId <mrca...@xxxxxxxxx> wrote:
The current release of libcatmath includes a friendly Tunnel
protocol for building a secure tunnel over the internet with minimal
effort. I have included an example server and client that
communicate with this protocol so the usage is well defined.


Maybe you misunderstood one of my earlier suggestions, but I'll re-
state it. It's in your best interest to maintain your non-related
functionality in different trees/projects. Your "libcatmath" if meant
to be a crypto library shouldn't have a codec in it, or tunnelling
code, etc... It should just have the crypto primitives your offering.

Try not thinking in terms of a libopenssl type thing if your meaning
is to be a general purpose crypto offering.

I wouldn't expect gzip [zlib] to include ciphers, even though it's
used quite a bit with crypto protocols. Why would I expect your
crypto code to include compression codecs? Also the naming of your
crypto side is a bit weird... I mean the path "math/src/math/" exists
in your tree.... maybe it should be called crypto instead [though it
should be separate from the non-crypto stuff].

Write your server/client code as if they were a user of a third party
library. It'll be good practice and a way to spot things you need to
fix in terms of usability or documentation. Pitting yourself as a
user is good role play. Also it means if I'm looking at your library
to use it for whatever reason there is the least amount of baggage as

Also can you speak to your intended license and the lineage of all the
source code? One thing people fear a lot about OSS projects of this
nature is who owns what. Even though my projects were written by me
[or code donated to the effort] I still have to put on a song and
dance show for users, and a few ended up not using it for various
reasons including legal.

Have you started a manual for the crypto api yet?

And finally, have you started your own version control [cvs, svn, git,
whatever] to keep track of development? Are you planning [ahead] to
allow outside contributions? What sort of development TODO list do
you have brewing in your head, what exact problem(s) are your
libraries meant to solve that others haven't addressed as well?

Not specifically because I'm looking to contribute (no offense, I
don't have time for my own OSS let alone others) but these are things
you should think about if you want to have a chance at a successful
OSS project.


Relevant Pages

  • Re: A cryptography solution for a client/server winforms app
    ... good idea if you want to learn crypto. ... you control both the client and server, you don't even need to use a ... code the client to ignore certificate trust errors. ... encrypt the memory stream. ...
  • Re: require crypto API
    ... libcrypto++5.2 - Crypto++ library ... libgcrypt-dev - LGPL Crypto library - development files ... libgcrypt11-dev - LGPL Crypto library - development files ... libssl0.9.6 - SSL shared libraries ...
  • [1/3] POHMELFS: Documentation.
    ... +POHMELFS: Parallel Optimized Host Message Exchange Layered File System. ... * Fast and scalable multithreaded userspace server. ... +command (or set of commands, which is frequently used during data writing: ... +POHMELFS is capable of full data channel encryption and/or strong crypto hashing. ...
  • [2/3] POHMELFS: Documentation.
    ... * Client is able to switch between different servers (if one goes down, ... Each transaction contains all information needed to process given command ... are asynchronous and are sent to the server during system writeback. ... +POHEMLFS is capable of full data channel encryption and/or strong crypto hashing. ...
  • Re: Fn Defn Style
    ... When I'm writing something alone, I do find that the benefits of heavy ... I actually find it easier to have separate functions in separate files ... Even when writing applications [I tend to work on libraries more] I ... Like we recently wrote an app with crypto and DB functionality. ...