[Delta] QCA 2

[Justin Karneges]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 27 May 2004 11:44 am, Marco Carnut wrote:
> Yeah, but a) some of my users insist on 2048+ bit keys, which take
> quite a lot longer and b) it's nice to have an option to threading,
> since not everything is thread-safe everywhere, some people may
> have complied Qt without threading support,... you get the picture.

When you have a blocking function, about the only solution is to use a thread, 
at least internally.  Otherwise you can't exit the call stack, and so the 
entire chain is blocked.  In a Qt program, the most sensible way of handling 
a long task is by having request functions that return immediately, and 
signals to indicate progress or completion.  What I propose is that the 
provider plugin should create an internal thread, invisible to the QCA user.  
This is how my NDns works, and means the user doesn't have to worry about 
thread-safety.

True, someone might be using a compiled Qt that does not have threading 
support, but I hope those days are coming to an end.  Qt 4 plans to make 
threading a staple feature.

> But now I'm back. In any event, thanks for QCA1 -- it made my job
> way easier. I'm preparing the site for my app (called "Kapanga")
> that uses it and soon you'll see where you code ended up. Ah,
> your name's in the credits too.

Great. :)

> Looking for the future, let's make QCA2 rock. Count on me to help.

One challenge with QCA is to strike a balance between complexity and 
simplicity.  There are a LOT of crypto details out there, but less choice 
means less confusion.  For example, when signing with a PrivateKey, QCA2 
doesn't have a choice in selecting the signing algorithm (ie, EMSA1,2,3,4).  
Maybe this is a bad thing..  I'm not sure yet.  In any case, if there are 
multiple choices for something, but most use-cases involve only one of them, 
then we should just go with that one, unless we personally have reasons to 
need more than that.

Let's go over your changes:

For RSA, you've added password protected PEM.  I have done this in QCA2, but I 
left out the 'algorithm' parameter, and just use TripleDES (Botan recommends 
everyone uses it).

What is RSA::context() ?  I hope it has no relation to fromNative() (which 
I've taken out).

What is RSA::toSPKAC() ?

What is "NON_EVP_BASED_STUFF" ?

#ifndef NON_EVP_BASED_STUFF
        bool sign(const QByteArray &a, QByteArray *out) const;
        int  verify(const QByteArray &a, QByteArray &sig) const;
#else
     bool sign(const QByteArray &a, QByteArray *out, bool oaep=false) const;
     bool verify(const QByteArray &a, QByteArray *out, bool oaep=false) const;
#endif

I noticed your functions above don't have the OAEP flag.  Normally I'd 
probably brush off OAEP as yet-another-useless-option, except that for some 
reason or another it is required by W3C's XML Encryption spec.

Just a comment on RSA components:

        QString modulus();
        QString exponent();

Thankfully I now have QBigInteger for these things. :)

I am just now getting to improving the Cert stuff, let's see what you've got 
here:

What is this?
  CertProperties extensions() const;

And this?
  int verifyChain(const QPtrList<Cert> &list, int *err=NULL, int *depth=NULL)

My guess is to allow cert validation outside of SSL, which would be 
interesting.

By the way,

  QString publicKeyAlgorithm() const;
  RSAKey toRSAKey();

the above functions will be replaced with:

  PublicKey subjectPublicKey() const;

These are evil, probably:

        void *toPkey();
        void *context();

Explain these:

  QString signatureAlgorithm() const;
  QString signature() const;

Finally, what exactly are PKCS7 and PKCS12?  At a glance, it seems PKCS7 is 
for generating certs.  I didn't think I'd go that far, but I don't see a 
problem with this. :)

- -Justin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAtkYT8+Nd5hn1dJ4RAoq/AJ42Ijrie76KHFb1FjzCAz4BsvZr4gCePAJ1
W4gMRvYdDOb/CqAFVKYkNNM=
=0p70
-----END PGP SIGNATURE-----