[Delta] QCA 2
justin-psi at affinix.com
Thu May 27 12:48:35 PDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
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.
> 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" ?
bool sign(const QByteArray &a, QByteArray *out) const;
int verify(const QByteArray &a, QByteArray &sig) const;
bool sign(const QByteArray &a, QByteArray *out, bool oaep=false) const;
bool verify(const QByteArray &a, QByteArray *out, bool oaep=false) const;
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:
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
What is this?
CertProperties extensions() const;
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
By the way,
QString publicKeyAlgorithm() const;
the above functions will be replaced with:
PublicKey subjectPublicKey() const;
These are evil, probably:
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. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Delta-affinix.com