Unnecessary SecureArray usage

I think when SecureArray was first introduced, I went
overboard with using it 
everywhere.  I already performed some reduction on its usage
awhile back 
(mainly for securelayer/securemessage), however I still
think it is overused.  
For example, Certificate::toDER() returns a SecureArray,
which is laughable 
since Certificates contain no sensitive secret key
material.

The main problem with all this usage is that it makes it
very easy to deplete 
all of your secure memory with operations that don't need
such protection.  
It would be best to reserve the secure memory for only the
most secure 
things.

Here's a breakdown of possibly unnecessary usage areas:

---

  1) core: arrayToHex accepts a SecureArray, but outputs a
QString (insecure) 
encoding of the input data.  That seems pointless.

  2) textfilter: the TextFilter class, as well as Hex and
Base64 which derive 
from it, use SecureArray everywhere.  Is this necessary?  If
it is, we may 
want to somehow make secure memory optional, or tell people
to not use these 
classes for activities that don't require high security. 
The main trouble is 
that while high security activities will likely be used on
small payloads 
(secret keys), activities that don't require security will
likely be used on 
large payloads (full documents).  Psi uses QCA::Base64 to
decode avatar 
images, which can potentially use lots of memory.  Pushing
the data through 
the TextFilter in small chunks can help reduce secure memory
usage.

  3) publickey: emsa3Encode.  I think neither the argument
nor the return 
value need to be secure.

  4) publickey: Sign/Verify.  Hmm, do people sign secret
keys that are 
otherwise unprotected?  If so, then we face a similar
problem as #2, where 
high security uses will probably be fine, but it's the
activities that don't 
require security which threaten the small secure memory
pool.  Again, pushing 
the data through in small chunks can help reduce the
effect.

  5) publickey: PublicKey::toDER()/fromDER() use
SecureArray.  It's public, 
this is not needed.

  6) cert: Certificate/CertificateRequest/CRL
toDER()/fromDER().  No secret 
data here.  Enough said.

  7) cert: PGPKey::toArray()/fromArray().  We use
SecureArray here just in 
case someone wants to export a passphrase-less PGP secret
key.  However, I 
wonder just how practical that is.  a) who would do this? 
b) wouldn't the 
underlying PGP implementation have already stored the secret
key on disk, 
defeating the point of protecting it now?

---

1, 3, 5, and 6 seem to be safe to change, with 6 having the
highest impact.

2, 4 and 7 I'm unsure about.

What do others think?

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Thursday 07 June 2007 10:01 pm, Justin Karneges wrote:
> ---
>
>   1) core: arrayToHex accepts a SecureArray, but
outputs a QString
> (insecure) encoding of the input data.  That seems
pointless.
>
>   2) textfilter: the TextFilter class, as well as Hex
and Base64 which
> derive from it, use SecureArray everywhere.  Is this
necessary?  If it is,
> we may want to somehow make secure memory optional, or
tell people to not
> use these classes for activities that don't require
high security.  The
> main trouble is that while high security activities
will likely be used on
> small payloads (secret keys), activities that don't
require security will
> likely be used on large payloads (full documents).  Psi
uses QCA::Base64 to
> decode avatar images, which can potentially use lots of
memory.  Pushing
> the data through the TextFilter in small chunks can
help reduce secure
> memory usage.
>
>   3) publickey: emsa3Encode.  I think neither the
argument nor the return
> value need to be secure.
>
>   4) publickey: Sign/Verify.  Hmm, do people sign
secret keys that are
> otherwise unprotected?  If so, then we face a similar
problem as #2, where
> high security uses will probably be fine, but it's the
activities that
> don't require security which threaten the small secure
memory pool.  Again,
> pushing the data through in small chunks can help
reduce the effect.
>
>   5) publickey: PublicKey::toDER()/fromDER() use
SecureArray.  It's public,
> this is not needed.
>
>   6) cert: Certificate/CertificateRequest/CRL
toDER()/fromDER().  No secret
> data here.  Enough said.
>
>   7) cert: PGPKey::toArray()/fromArray().  We use
SecureArray here just in
> case someone wants to export a passphrase-less PGP
secret key.  However, I
> wonder just how practical that is.  a) who would do
this?  b) wouldn't the
> underlying PGP implementation have already stored the
secret key on disk,
> defeating the point of protecting it now?
>
> ---
>
> 1, 3, 5, and 6 seem to be safe to change, with 6 having
the highest impact.
>
> 2, 4 and 7 I'm unsure about.

Following up to myself ...

I've committed 6.

Jack Lloyd (of Botan) suggests that 2 is probably safe to
do.  It is unlikely 
you'd Base64 secret key data that isn't already encrypted.

Jack also says that for sign/verify, the signature probably
doesn't need to be 
secure.  I guess the plaintext may still need to be secure
though, in case 
someone signs a raw secret key.  For now I'll consider
myself unsure about 
the plaintext part of 4.

I'm still unsure about 7.  PGP key import/export is probably
a rare enough 
operation that the impact would be minimal if I left this
alone.

Therefore, I'll take care of 1, 2, 3, 4 (signature only),
and 5.

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com

On Monday 11 June 2007 7:56 pm, Justin Karneges wrote:
> On Thursday 07 June 2007 10:01 pm, Justin Karneges
wrote:
> > ---
> >
> >   1) core: arrayToHex accepts a SecureArray, but
outputs a QString
> > (insecure) encoding of the input data.  That seems
pointless.
> >
> >   2) textfilter: the TextFilter class, as well as
Hex and Base64 which
> > derive from it, use SecureArray everywhere.  Is
this necessary?  If it
> > is, we may want to somehow make secure memory
optional, or tell people to
> > not use these classes for activities that don't
require high security. 
> > The main trouble is that while high security
activities will likely be
> > used on small payloads (secret keys), activities
that don't require
> > security will likely be used on large payloads
(full documents).  Psi
> > uses QCA::Base64 to decode avatar images, which
can potentially use lots
> > of memory.  Pushing the data through the
TextFilter in small chunks can
> > help reduce secure memory usage.
> >
> >   3) publickey: emsa3Encode.  I think neither the
argument nor the return
> > value need to be secure.
> >
> >   4) publickey: Sign/Verify.  Hmm, do people sign
secret keys that are
> > otherwise unprotected?  If so, then we face a
similar problem as #2,
> > where high security uses will probably be fine,
but it's the activities
> > that don't require security which threaten the
small secure memory pool. 
> > Again, pushing the data through in small chunks
can help reduce the
> > effect.
> >
> >   5) publickey: PublicKey::toDER()/fromDER() use
SecureArray.  It's
> > public, this is not needed.
> >
> >   6) cert: Certificate/CertificateRequest/CRL
toDER()/fromDER().  No
> > secret data here.  Enough said.
> >
> >   7) cert: PGPKey::toArray()/fromArray().  We use
SecureArray here just
> > in case someone wants to export a passphrase-less
PGP secret key. 
> > However, I wonder just how practical that is.  a)
who would do this?  b)
> > wouldn't the underlying PGP implementation have
already stored the secret
> > key on disk, defeating the point of protecting it
now?
> >
> > ---
> >
> > 1, 3, 5, and 6 seem to be safe to change, with 6
having the highest
> > impact.
> >
> > 2, 4 and 7 I'm unsure about.
>
> Following up to myself ...
>
> I've committed 6.
>
> Jack Lloyd (of Botan) suggests that 2 is probably safe
to do.  It is
> unlikely you'd Base64 secret key data that isn't
already encrypted.
>
> Jack also says that for sign/verify, the signature
probably doesn't need to
> be secure.  I guess the plaintext may still need to be
secure though, in
> case someone signs a raw secret key.  For now I'll
consider myself unsure
> about the plaintext part of 4.
>
> I'm still unsure about 7.  PGP key import/export is
probably a rare enough
> operation that the impact would be minimal if I left
this alone.
>
> Therefore, I'll take care of 1, 2, 3, 4 (signature
only), and 5.

3, 4 (signature only), 5, 7 committed.

I went ahead with 7 because it just doesn't seem appropriate
to make all PGP 
imports using secure memory when 99.99999% of the time it
will be for public 
keys (and I'm imagining Psi doing auto-imports).  It is
clear, then, that if 
we need secure import/export for unencrypted PGP secret
keys, we'd want 
secure and insecure to be separate methods.  For now I've
left out a secure 
method, but we can always add one if there is ever demand
(though I suspect 
this will never happen).

This leaves 1 and 2.  I'm still unsure about 4 (plaintext).

-Justin
_______________________________________________
delta mailing list
deltalists.affinix.com
http://lists.affinix.com/listinfo.cgi/delta-affinix.com