Discussion:
[OLPC Security] [Techteam] Crypto export and python-crypto
C. Scott Ananian
2008-06-02 21:26:48 UTC
Permalink
Jameson Chema Quinn is basing his crypto code for bundle signing on python-crypto: http://www.amk.ca/python/code/crypto.html
I personally would prefer that crypto code be based on the same
algorithms and formats we use elsewhere, as documented at:
http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease

I took great care to ensure that the every bit in the format is
documented, and traceable in most cases to best practices outlined in
a standards document. This is in marked contrast to places where
you'll find handwaving about "an RSA signature" (say) when there are
multiple ways to use RSA to generate a signature, many of them in fact
terribly bad. (For example, OpenPGP uses an RSA signature scheme
vulnerable to an adaptive chosen ciphertext attack, and the known
covert channels in DSA signatures became very problematic in the
recent Debian/OpenSSL issues.)

Python bindings are at
http://dev.laptop.org/git?p=bios-crypto;a=summary and are available in
the olpccontents RPM on the XO.

Avoiding the need to declare additional crypto code for export is a
pleasant side effect of using the existing audited codebase; Michael
can tell you the extent to which that is (or is not) necessary in the
case of python-crypto. I don't see anything in python-crypto which is
not included in bios-crypto; most of what python-crypto provides is
either out-of-date (should not be used in new applications) or
duplicates functionality already provided by the standard python
libraries (http://docs.python.org/lib/crypto.html).

Security-sensitive code should also be reviewed on the security list.
Jameson "Chema" Quinn
2008-06-03 13:30:51 UTC
Permalink
Jameson Chema Quinn is basing his crypto code for bundle signing on
python-crypto: http://www.amk.ca/python/code/crypto.html
I personally would prefer that crypto code be based on the same
http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease
On algorithms, I fully agree. Signatures, for instance, should be based on
pkcs1v2.1.

On formats, I agree in principle. But as your own email points out, there
are already two different signature formats invented for the XO, because of
specifics about what is to be signed. If these do not work for my needs, I
do not see why I should not invent another.
I took great care to ensure that the every bit in the format is
documented, and traceable in most cases to best practices outlined in
a standards document. This is in marked contrast to places where
you'll find handwaving about "an RSA signature" (say) when there are
multiple ways to use RSA to generate a signature, many of them in fact
terribly bad. (For example, OpenPGP uses an RSA signature scheme
vulnerable to an adaptive chosen ciphertext attack, and the known
covert channels in DSA signatures became very problematic in the
recent Debian/OpenSSL issues.)
The OpenPGP attack you mention has to do with encryption, not signatures.
(And it leaks a tiny fraction of plaintext for 2^16 encryption operations
per block). Signatures, becauses they cannot fail partially like this, are
inherently more secure than encryption; a mistake like this in a signature
would just reduce the exponent on the difficulty of forgery by a small
amount, making no practical difference.
Python bindings are at
http://dev.laptop.org/git?p=bios-crypto;a=summary and are available in
the olpccontents RPM on the XO.
Now you're talking. I will still have to embed these signatures in a format
to fit my purposes, but it appears I can use this code instead of pycrypto.
Avoiding the need to declare additional crypto code for export is a
pleasant side effect of using the existing audited codebase; Michael
can tell you the extent to which that is (or is not) necessary in the
case of python-crypto. I don't see anything in python-crypto which is
not included in bios-crypto; most of what python-crypto provides is
either out-of-date (should not be used in new applications) or
duplicates functionality already provided by the standard python
libraries (http://docs.python.org/lib/crypto.html).
The standard libraries provide only hash functionality. Pycrypto provides
symmetric and public-key ciphers. I think it would be good in the long term
to have good python bindings for these latter functions - but since with
what you've given me I don't need that, I will let that lie. (Openpgp may be
the right solution here).
Security-sensitive code should also be reviewed on the security list.
From a software engineering standpoint, I'd be much happier if we just
decided to use JAR files
http://en.wikipedia.org/wiki/JAR_(file_format)<http://en.wikipedia.org/wiki/JAR_%28file_format%29>which already have a
well-defined signature mechanism, instead of designing our own bespoke
thing yet again (see
http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2 and
http://wiki.laptop.org/go/Contents_manifest_specification ).
--scott
I did look at JAR files, and decided that their format lacked some desirable
features. They are based on md5 hashes, which are close to broken; they do
not allow for granting privileges to secondary keys, which means that
Glucose can't take any of the key management burden off the shoulders of the
user; they interact poorly with differential versioning storage; and they do
not allow for unsigned content in a signed bundle, which makes localization
more of a pain. Any one of those problems I could have lived with, the three
together seem to me like a good enough reason for changing a format. And
once you make any change, you break existing tools, so there is no reason to
the format partially.

The contents manifest specification does not fit my needs either.

Thanks for responding, I hope to continue the dialog,
Jameson Quinn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/620e86e6/attachment.htm
C. Scott Ananian
2008-06-03 14:41:40 UTC
Permalink
On Tue, Jun 3, 2008 at 9:30 AM, Jameson Chema Quinn
Post by Jameson &quot;Chema&quot; Quinn
On formats, I agree in principle. But as your own email points out, there
are already two different signature formats invented for the XO, because of
specifics about what is to be signed. If these do not work for my needs, I
do not see why I should not invent another.
Exactly because we already have two, we should avoid having *three*!

It would be better to patch one of these so we only have *one*. (And
what are the two formats you are referring to?)
Post by Jameson &quot;Chema&quot; Quinn
The OpenPGP attack you mention has to do with encryption, not signatures.
Please read page 25 of
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf. Although
there is (yet) no practical attack, it (like MD5) is not recommended
for new applications.
Post by Jameson &quot;Chema&quot; Quinn
I did look at JAR files, and decided that their format lacked some desirable
features. They are based on md5 hashes, which are close to broken; they do
You are wrong. http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures
Post by Jameson &quot;Chema&quot; Quinn
not allow for granting privileges to secondary keys, which means that
You can have any number of .SF signature files, signing any
combination of the contents.
Post by Jameson &quot;Chema&quot; Quinn
user; they interact poorly with differential versioning storage; and they do
They in fact interact quite well. See
http://wiki.laptop.org/go/XO_updater#Application_updater
Post by Jameson &quot;Chema&quot; Quinn
not allow for unsigned content in a signed bundle, which makes localization
I do not believe this to be the case.
Post by Jameson &quot;Chema&quot; Quinn
more of a pain. Any one of those problems I could have lived with, the three
together seem to me like a good enough reason for changing a format. And
And in the absence of any of the three?
Post by Jameson &quot;Chema&quot; Quinn
The contents manifest specification does not fit my needs either.
I'll let this pass, for now, but I explicitly designed it to fit both
the OS and activity update case, so I find this statement puzzling. I
think what you mean is, "it does not solve *all* my problems for me",
and this is because it is not designed to. It is just one part of a
solution. But I prefer the JAR file format for activities anyway, so
I don't think it's worth belaboring this.
--scott
--
( http://cscott.net/ )
Jameson &quot;Chema&quot; Quinn
2008-06-03 17:55:39 UTC
Permalink
I just sent this message to cscott privately by mistake.

---------- Forwarded message ----------
From: Jameson Chema Quinn <jquinn at cs.oberlin.edu>
Date: Tue, Jun 3, 2008 at 11:54 AM
Subject: Re: [OLPC Security] [Techteam] Crypto export and python-crypto
To: "C. Scott Ananian" <cscott at laptop.org>


Thanks again for responding; while I still disagree, I am definitely
learning from this conversation.
Post by C. Scott Ananian
On Tue, Jun 3, 2008 at 9:30 AM, Jameson Chema Quinn
Post by Jameson &quot;Chema&quot; Quinn
On formats, I agree in principle. But as your own email points out, there
are already two different signature formats invented for the XO, because
of
Post by Jameson &quot;Chema&quot; Quinn
specifics about what is to be signed. If these do not work for my needs,
I
Post by Jameson &quot;Chema&quot; Quinn
do not see why I should not invent another.
Exactly because we already have two, we should avoid having *three*!
It would be better to patch one of these so we only have *one*. (And
what are the two formats you are referring to?)
http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats<http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease>
and
http://wiki.laptop.org/go/Contents_manifest_specification
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
The OpenPGP attack you mention has to do with encryption, not signatures.
Please read page 25 of
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf. Although
there is (yet) no practical attack, it (like MD5) is not recommended
for new applications.
This is true, but totally separate from the attack you mentioned, which is
in fact a practical (though limited) attack. Without reading the references,
the implication is that v2.1 is better than v1.5 only in terms of its
provability; not only are there no practical attacks on v1.5, there is not
even any intimation of any theoretical/incomplete ones, just the theoretical
possibility that such might exist.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
I did look at JAR files, and decided that their format lacked some
desirable
Post by Jameson &quot;Chema&quot; Quinn
features. They are based on md5 hashes, which are close to broken; they
do
You are wrong.
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures
My reading of this is that there are three stages to a signature.
1. manifest file: each subfile is signed by an arbitrary set of hashes
including md5
2. .sf file: an arbitrary subset of the files in manifest. Each entry in the
manifest, including hashes, is signed by md5 alone.
3. digital signature: an RSA (+md5), DSA, or PGP signature on the .sf file.

Thus md5 appears 2 or 3 times in this chain, and in step 2 there are no
options or redundancy. While a naive view would say that the constraints on
the manifest entry format are tight enough to make it more difficult to
forge a signature by breaking step 2, a meet-in-the-middle
attack<http://en.wikipedia.org/wiki/Meet-in-the-middle_attack>could
theoretically break it in as little as twice the time needed to break
md5. Also, step 3 does not allow for a simple rsa+shaxxx signature without
using pgp.

<http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures>
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
not allow for granting privileges to secondary keys, which means that
You can have any number of .SF signature files, signing any
combination of the contents.
You are right. So it is possible to abuse the format to allow this by
signing signatures. However, the metadata on signatures must then be
separate - either in separate files or as magic attributes in the manifest.
This feels like an ugly hack to me.

(Sorry, I realize that I am not fully explaining my thoughts here, because
it is beside the point. I assert that there is a way, but there is no good
way, within this format, for a master key to say "Signatures from key xxx
are valid, as long as their signed metadata states that they were requested
by activity yyy". Explaining the details of the bad way I can imagine is
unimportant; if you have a good way, let's talk about that instead.)
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
user; they interact poorly with differential versioning storage; and they
do
They in fact interact quite well. See
http://wiki.laptop.org/go/XO_updater#Application_updater
Ouch. This is somewhat of a monster of a year-old unimplemented
specification. It definitely has its attractions, but does not address the
problem I was attempting to refer to: compressed files will have much
noisier diffs from version to version. On a compressing, versioning file
system like jffs + olpcfs, storage should be in an uncompressed archive
format like tar IMO. Note that, with Develop, there may be dozens of
versions of one activity on the same machine; the redundancy between
versions dominates the redundancy within a given version (and the latter is
taken care of by jffs2 at the lowest level anyway.)
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
not allow for unsigned content in a signed bundle, which makes
localization
I do not believe this to be the case.
You are correct, I was mistaken.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
more of a pain. Any one of those problems I could have lived with, the
three
Post by Jameson &quot;Chema&quot; Quinn
together seem to me like a good enough reason for changing a format. And
And in the absence of any of the three?
Post by Jameson &quot;Chema&quot; Quinn
The contents manifest specification does not fit my needs either.
I'll let this pass, for now, but I explicitly designed it to fit both
the OS and activity update case, so I find this statement puzzling. I
think what you mean is, "it does not solve *all* my problems for me",
and this is because it is not designed to. It is just one part of a
solution. But I prefer the JAR file format for activities anyway, so
I don't think it's worth belaboring this.
Obviously, I need to state my design goals more clearly and explicitly; it
is my fault you are puzzled. I will begin to compose an email to do that
now, meanwhile I will send this off.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/7f7a476e/attachment-0001.htm
C. Scott Ananian
2008-06-03 18:19:26 UTC
Permalink
On Tue, Jun 3, 2008 at 1:55 PM, Jameson Chema Quinn
Post by C. Scott Ananian
Post by C. Scott Ananian
On Tue, Jun 3, 2008 at 9:30 AM, Jameson Chema Quinn
Post by Jameson &quot;Chema&quot; Quinn
On formats, I agree in principle. But as your own email points out, there
are already two different signature formats invented for the XO, because of
specifics about what is to be signed. If these do not work for my needs, I
do not see why I should not invent another.
Exactly because we already have two, we should avoid having *three*!
It would be better to patch one of these so we only have *one*. (And
what are the two formats you are referring to?)
http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats
and
http://wiki.laptop.org/go/Contents_manifest_specification
That is a *manifest* specification and a *signature* specification,
not two signature specifications.
Post by C. Scott Ananian
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
The OpenPGP attack you mention has to do with encryption, not signatures.
Please read page 25 of
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf. Although
there is (yet) no practical attack, it (like MD5) is not recommended
for new applications.
This is true, but totally separate from the attack you mentioned, which is
in fact a practical (though limited) attack. Without reading the references,
the implication is that v2.1 is better than v1.5 only in terms of its
provability; not only are there no practical attacks on v1.5, there is not
even any intimation of any theoretical/incomplete ones, just the theoretical
possibility that such might exist.
Like the theoretical future attacks on MD5. This isn't really worth
discussion. If RSA suggests that new applications don't use v1.5,
you're not going to convince me I should use it.
Post by C. Scott Ananian
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
I did look at JAR files, and decided that their format lacked some desirable
features. They are based on md5 hashes, which are close to broken; they do
You are wrong.
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures
My reading of this is that there are three stages to a signature.
1. manifest file: each subfile is signed by an arbitrary set of hashes
including md5
2. .sf file: an arbitrary subset of the files in manifest. Each entry in the
manifest, including hashes, is signed by md5 alone.
3. digital signature: an RSA (+md5), DSA, or PGP signature on the .sf file.
Thus md5 appears 2 or 3 times in this chain, and in step 2 there are no
options or redundancy. While a naive view would say that the constraints on
the manifest entry format are tight enough to make it more difficult to
forge a signature by breaking step 2, a meet-in-the-middle attack could
theoretically break it in as little as twice the time needed to break md5.
Also, step 3 does not allow for a simple rsa+shaxxx signature without using
pgp.
I gave you the wrong URL. Let's reboot with
http://java.sun.com/javase/6/docs/technotes/guides/jar/index.html

which correctly deprecates the MD5-ish-ness of earlier specs.

(And don't you find it ironic that you're arguing for SHA against MD5
here, but for v1.5 RSA signatures against v2.0 above?)
Post by C. Scott Ananian
(Sorry, I realize that I am not fully explaining my thoughts here, because
it is beside the point. I assert that there is a way, but there is no good
way, within this format, for a master key to say "Signatures from key xxx
are valid, as long as their signed metadata states that they were requested
by activity yyy". Explaining the details of the bad way I can imagine is
unimportant; if you have a good way, let's talk about that instead.)
Why does this have to be part of the JAR file format? Isn't this a
function of rainbow?
The JAR file has a collection of signatures. Determining whether this
is a *sufficient* collection of signatures is not something that JAR
should be doing. That is application-level semantics. I content that
there is nothing OLPC-specific about a collection of files and
signatures.
Post by C. Scott Ananian
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
user; they interact poorly with differential versioning storage; and they do
They in fact interact quite well. See
http://wiki.laptop.org/go/XO_updater#Application_updater
Ouch. This is somewhat of a monster of a year-old unimplemented
specification. It definitely has its attractions, but does not address the
problem I was attempting to refer to: compressed files will have much
noisier diffs from version to version. On a compressing, versioning file
system like jffs + olpcfs, storage should be in an uncompressed archive
format like tar IMO. Note that, with Develop, there may be dozens of
versions of one activity on the same machine; the redundancy between
versions dominates the redundancy within a given version (and the latter is
taken care of by jffs2 at the lowest level anyway.)
Zip files can, of course, be stored with uncompressed entries. On
disk format does not need to match distribution format. Delta storage
on the file system (or journal) makes most of what you seem to be
claiming irrelevant. Perhaps you need to study the internal structure
of ZIP more closely? (While you are at it, studying how rsync works
will help you understand how compression and delta storage interact;
in particular look at the --rsyncable option to gzip.)
Post by C. Scott Ananian
Obviously, I need to state my design goals more clearly and explicitly; it
is my fault you are puzzled. I will begin to compose an email to do that
now, meanwhile I will send this off.
Yes. Rebooting to
http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2, there is no
use case or rationale, just a long list of required files. And the
second sentence on that page is false. I'd recommend *starting* with
the rationale, getting it discussed properly, and *then* working out
the on-disk structure. [Again, I claim that there are no requirements
on the on-disk structure which JAR can not provide.]

Also, you seem to be trying to argue for a particular security model
(what Bitfrost should check, who it should trust, what files need to
be authenticated, etc) at the same time you are making detailed file
system layout decisions and then arguing for certain compression
formats on vague efficiency grounds. Separating these is the first
step in constructing a readable specification. Minimizing each
section is the second step. =)
--scott
--
( http://cscott.net/ )
Jameson &quot;Chema&quot; Quinn
2008-06-03 21:36:45 UTC
Permalink
I have updated
http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2#Design_goals
Post by C. Scott Ananian
Like the theoretical future attacks on MD5. This isn't really worth
discussion. If RSA suggests that new applications don't use v1.5,
you're not going to convince me I should use it.
Sorry, my point was not that 1.5 was good, just that you went overboard in
criticizing OpenSSL for using it. Your original critique mentioned a
specific attack, remember.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
I did look at JAR files, and decided that their format lacked some desirable
features. They are based on md5 hashes, which are close to broken;
they
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
do
You are wrong.
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures
Post by Jameson &quot;Chema&quot; Quinn
My reading of this is that there are three stages to a signature.
1. manifest file: each subfile is signed by an arbitrary set of hashes
including md5
2. .sf file: an arbitrary subset of the files in manifest. Each entry in
the
Post by Jameson &quot;Chema&quot; Quinn
manifest, including hashes, is signed by md5 alone.
3. digital signature: an RSA (+md5), DSA, or PGP signature on the .sf
file.
Post by Jameson &quot;Chema&quot; Quinn
Thus md5 appears 2 or 3 times in this chain, and in step 2 there are no
options or redundancy. While a naive view would say that the constraints
on
Post by Jameson &quot;Chema&quot; Quinn
the manifest entry format are tight enough to make it more difficult to
forge a signature by breaking step 2, a meet-in-the-middle attack could
theoretically break it in as little as twice the time needed to break
md5.
Post by Jameson &quot;Chema&quot; Quinn
Also, step 3 does not allow for a simple rsa+shaxxx signature without
using
Post by Jameson &quot;Chema&quot; Quinn
pgp.
I gave you the wrong URL. Let's reboot with
http://java.sun.com/javase/6/docs/technotes/guides/jar/index.html
which correctly deprecates the MD5-ish-ness of earlier specs.
I get the same error on reboot. Reading that file, I see no relevant change
to the section in question. It still looks as if it has at least one, and up
to 3, MD5-only steps to me.
Post by C. Scott Ananian
(And don't you find it ironic that you're arguing for SHA against MD5
here, but for v1.5 RSA signatures against v2.0 above?)
Not for v1.5, just against being too dismissive. I agree, v2.0 is the way to
go.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
(Sorry, I realize that I am not fully explaining my thoughts here,
because
Post by Jameson &quot;Chema&quot; Quinn
it is beside the point. I assert that there is a way, but there is no
good
Post by Jameson &quot;Chema&quot; Quinn
way, within this format, for a master key to say "Signatures from key xxx
are valid, as long as their signed metadata states that they were
requested
Post by Jameson &quot;Chema&quot; Quinn
by activity yyy". Explaining the details of the bad way I can imagine is
unimportant; if you have a good way, let's talk about that instead.)
Why does this have to be part of the JAR file format? Isn't this a
function of rainbow?
The JAR file has a collection of signatures. Determining whether this
is a *sufficient* collection of signatures is not something that JAR
should be doing. That is application-level semantics. I content that
there is nothing OLPC-specific about a collection of files and
signatures.
If all or most signatures have a special, one-to-one relationship with some
associated metadata, and in some cases cannot even be created by an activity
without Glucose adding that metadata, it seems to me there are several
reasons to prefer including such metadata in the same file or at least the
same directory. This is not possible with jar files, so any solution is more
or less a hack.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
user; they interact poorly with differential versioning storage; and they do
They in fact interact quite well. See
http://wiki.laptop.org/go/XO_updater#Application_updater
Ouch. This is somewhat of a monster of a year-old unimplemented
specification. It definitely has its attractions, but does not address
the
Post by Jameson &quot;Chema&quot; Quinn
problem I was attempting to refer to: compressed files will have much
noisier diffs from version to version. On a compressing, versioning file
system like jffs + olpcfs, storage should be in an uncompressed archive
format like tar IMO. Note that, with Develop, there may be dozens of
versions of one activity on the same machine; the redundancy between
versions dominates the redundancy within a given version (and the latter
is
Post by Jameson &quot;Chema&quot; Quinn
taken care of by jffs2 at the lowest level anyway.)
Zip files can, of course, be stored with uncompressed entries. On
disk format does not need to match distribution format. Delta storage
on the file system (or journal) makes most of what you seem to be
claiming irrelevant. Perhaps you need to study the internal structure
of ZIP more closely? (While you are at it, studying how rsync works
will help you understand how compression and delta storage interact;
in particular look at the --rsyncable option to gzip.)
I am specifically talking about delta storage. A naive tgz causes an
obnoxiously large delta. A tarfile can have tiny deltas. I am not sure where
zip and --rsyncable lie on this continuum, and whether they are good enough.
(--rsyncable is interesting, and I was not aware of it.) I do not even know
which of those two options is better. This is a question that should be
answered empirically, with some real bundles as examples.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
Obviously, I need to state my design goals more clearly and explicitly;
it
Post by Jameson &quot;Chema&quot; Quinn
is my fault you are puzzled. I will begin to compose an email to do that
now, meanwhile I will send this off.
Yes. Rebooting to
http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2, there is no
use case or rationale, just a long list of required files. And the
second sentence on that page is false. I'd recommend *starting* with
the rationale, getting it discussed properly, and *then* working out
the on-disk structure. [Again, I claim that there are no requirements
on the on-disk structure which JAR can not provide.]
Can, yes. However, when is it worth using an established format? I would
argue that when it would be excruciating to use existing tools for that
format by hand; when most such tools are written in a language that does not
even run on your target platform; and when your special needs are large
enough and against the grain of the format enough that using that format
makes the job harder, both in terms of initial programming effort and
upkeep; then the gain is not worth it.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/4e544019/attachment-0001.htm
C. Scott Ananian
2008-06-03 23:22:50 UTC
Permalink
On Tue, Jun 3, 2008 at 5:36 PM, Jameson Chema Quinn
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
Like the theoretical future attacks on MD5. This isn't really worth
discussion. If RSA suggests that new applications don't use v1.5,
you're not going to convince me I should use it.
Sorry, my point was not that 1.5 was good, just that you went overboard in
criticizing OpenSSL for using it. Your original critique mentioned a
specific attack, remember.
OpenPGP, not OpenSSL. And PKCS v2.1 was released 6 years ago; OpenPGP
still has not provided a way to use RSA-PSS.

The specific attack was on OpenSSL, where the use of DSA caused a poor
random number generator on the server to leak even a
strongly-generated private key on the client.
http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
features. They are based on md5 hashes, which are close to broken;
You are wrong.
[...]
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
I gave you the wrong URL. Let's reboot with
http://java.sun.com/javase/6/docs/technotes/guides/jar/index.html
which correctly deprecates the MD5-ish-ness of earlier specs.
I get the same error on reboot. Reading that file, I see no relevant change
to the section in question. It still looks as if it has at least one, and up
to 3, MD5-only steps to me.
OK, I'm spending a lot of time writing replies to you, and you're not
reading the links I'm sending you. Please work harder if you want me
to keep responding. Please search for 'MD5' in the spec and tell me
what it says in the last hit. Thanks.
Post by Jameson &quot;Chema&quot; Quinn
If all or most signatures have a special, one-to-one relationship with some
associated metadata, and in some cases cannot even be created by an activity
without Glucose adding that metadata, it seems to me there are several
reasons to prefer including such metadata in the same file or at least the
same directory. This is not possible with jar files, so any solution is more
or less a hack.
Your reasoning is poor. You are creating your own archive format
because you don't want to create an extra file? Geez.
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
Zip files can, of course, be stored with uncompressed entries. On
disk format does not need to match distribution format. Delta storage
on the file system (or journal) makes most of what you seem to be
claiming irrelevant. Perhaps you need to study the internal structure
of ZIP more closely? (While you are at it, studying how rsync works
will help you understand how compression and delta storage interact;
in particular look at the --rsyncable option to gzip.)
I am specifically talking about delta storage. A naive tgz causes an
obnoxiously large delta. A tarfile can have tiny deltas. I am not sure where
zip and --rsyncable lie on this continuum, and whether they are good enough.
(--rsyncable is interesting, and I was not aware of it.) I do not even know
which of those two options is better. This is a question that should be
answered empirically, with some real bundles as examples.
AGAIN, PLEASE READ THE STUFF I ASK YOU TO READ BEFORE MAKING ME READ A RESPONSE!

Thank you.
Post by Jameson &quot;Chema&quot; Quinn
Can, yes. However, when is it worth using an established format? I would
argue that when it would be excruciating to use existing tools for that
format by hand; when most such tools are written in a language that does not
even run on your target platform; and when your special needs are large
enough and against the grain of the format enough that using that format
makes the job harder, both in terms of initial programming effort and
upkeep; then the gain is not worth it.
http://www.google.com/search?q=fastjar

It is worth using existing formats even if you have to rewrite all
your tools from scratch, because the format has been used and tested
and understood by more people than just you. In fact, formats with
multiple implementations are *preferred*, because that shows that they
are well understood.
--scott
--
( http://cscott.net/ )
Jameson &quot;Chema&quot; Quinn
2008-06-04 02:59:56 UTC
Permalink
Post by C. Scott Ananian
OK, I'm spending a lot of time writing replies to you, and you're not
reading the links I'm sending you. Please work harder if you want me
to keep responding. Please search for 'MD5' in the spec and tell me
what it says in the last hit. Thanks.
Sorry, I missed that. I was misled by the use of the definite article in
the sentence fragment "The corresponding signature file would be:"
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
If all or most signatures have a special, one-to-one relationship with
some
Post by Jameson &quot;Chema&quot; Quinn
associated metadata, and in some cases cannot even be created by an
activity
Post by Jameson &quot;Chema&quot; Quinn
without Glucose adding that metadata, it seems to me there are several
reasons to prefer including such metadata in the same file or at least
the
Post by Jameson &quot;Chema&quot; Quinn
same directory. This is not possible with jar files, so any solution is
more
Post by Jameson &quot;Chema&quot; Quinn
or less a hack.
Your reasoning is poor. You are creating your own archive format
because you don't want to create an extra file? Geez.
I am creating my own archive format because the existing one solves
essentially none of the problems I am interested in, and in fact makes it
harder to solve them and less intuitive for others to understand the
solutions.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
Post by C. Scott Ananian
Zip files can, of course, be stored with uncompressed entries. On
disk format does not need to match distribution format. Delta storage
on the file system (or journal) makes most of what you seem to be
claiming irrelevant. Perhaps you need to study the internal structure
of ZIP more closely? (While you are at it, studying how rsync works
will help you understand how compression and delta storage interact;
in particular look at the --rsyncable option to gzip.)
I am specifically talking about delta storage. A naive tgz causes an
obnoxiously large delta. A tarfile can have tiny deltas. I am not sure
where
Post by Jameson &quot;Chema&quot; Quinn
zip and --rsyncable lie on this continuum, and whether they are good
enough.
Post by Jameson &quot;Chema&quot; Quinn
(--rsyncable is interesting, and I was not aware of it.) I do not even
know
Post by Jameson &quot;Chema&quot; Quinn
which of those two options is better. This is a question that should be
answered empirically, with some real bundles as examples.
AGAIN, PLEASE READ THE STUFF I ASK YOU TO READ BEFORE MAKING ME READ A RESPONSE!
Thank you.
Please, let's treat each other with respect. I did respond to you. It is a
fact that both zip an gzip --rsyncable still have the potential to propagate
a small change, even though both of them do place limits on how far this
change can propagate. I acknowledged this in my response.

You may think it ridiculous that I want empirical data on the relative
sizes. You may be right that zip format can be assumed to be good enough,
given that the most dysfunctional case for zip deltas - a single large
subfile subject to frequent, small, sequentially-early changes - will be
uncommon in a bundle. But please do not yell at me and tell me to "read the
stuff" when you did not give me a link, I did do a google, and my response
reflected that. I have a similar impression that you are reading my
responses superficially, yet I know misunderstandings happen between
intelligent people.
Post by C. Scott Ananian
Post by Jameson &quot;Chema&quot; Quinn
Can, yes. However, when is it worth using an established format? I would
argue that when it would be excruciating to use existing tools for that
format by hand; when most such tools are written in a language that does
not
Post by Jameson &quot;Chema&quot; Quinn
even run on your target platform; and when your special needs are large
enough and against the grain of the format enough that using that format
makes the job harder, both in terms of initial programming effort and
upkeep; then the gain is not worth it.
http://www.google.com/search?q=fastjar
A tool which does nothing in terms of signatures.
Post by C. Scott Ananian
<http://www.google.com/search?q=fastjar>
It is worth using existing formats even if you have to rewrite all
your tools from scratch, because the format has been used and tested
and understood by more people than just you. In fact, formats with
multiple implementations are *preferred*, because that shows that they
are well understood.
You are right, if those formats solve the problem you need to solve. If,
even after you rewrite the tools from scratch, they get you no closer to a
solution than you started out, it is at least debatable if that was worth
it.

Consider:
Jar defines only two signature formats (md5-rsa and dsa), both of which are
ready for deprecation. So I have to do that myself.

Jar gives no inherent way to decide what content does or does not need a
signature. So I have to do that myself. (And when I do, I must, for
compliance, uselessly duplicate the list of files which need a signature as
many times as I have signatures on those files.)

Jar gives me, as far as I can tell, no useful tools for building valid
bundles (using fastjar takes about the same number of lines of python as
doing it natively from python, though it is probably faster). So I might as
well do that myself.

Jar does not allow metadata to be included with a signature. So I have to
keep track of metadata in a separate file - not too hard, as you say. Worse,
I have to write the glucose signing service such that it puts this minor but
confusing job in the lap of any other activity which wants to use
signatures. So here, I'm worse off than I was without it.

Even when I do all that, Jar does not give me any help in defining what
chain of signatures is valid. Again, do it myself.

What does it give me? Some directory, file, and attribute names; some
definitions of whitespace, picky line length limits, and some more elements
of an underdefined manifest specification. That's great; I would be happy to
use the naming and other conventions from the jar spec, insofar as they
don't get in my way. But since any checker which validates jar spec
compliance will get me about 10% of the way to proving that a given bundle
is valid by my definition, the fact is in effect I am writing my own spec
anyway. I would say that is more helpful to make that fact clear by
deviating from the jar spec when it is convenient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/0d3c41f0/attachment-0001.htm
C. Scott Ananian
2008-06-04 16:21:33 UTC
Permalink
I'm taking a time out from this thread for a bit.

Please take it as a given that using existing formats is preferable to
rolling your own, and concentrate on clearly writing up the security
details (what should be signed, by whom, how delegation might work)
and trying to find a set of minimal changes to existing mechanisms to
support these, instead of insisting that you must throw everything out
and start from scratch. There is a large benefit to reusing existing
formats and making gradual changes, and this benefit far outweighs the
sort of minor quibbles you have been presenting.

In particular, the http://wiki.laptop.org/go/Activity_bundles spec
already has manifest and signature components specified, and IMO
separate standalone "translation packs" of the form saymindu has been
working on are a much better solution to the "independent translation"
problem than your elaborate system of signed and unsigned files.

Further, IMO group maintenance of an activity is best solved by simply
creating a keypair shared by all maintainers of the activity. Yes,
this isn't as intellectually stimulating as an elaborate web of trust
of delegated signatures, but it is 95% as functional for much less
conceptual and implementation cost. More elaborate group mechanisms
can be built on this simple base; we don't need to jump immediately to
an all-singing all-dancing solution.

Please show me that you can make small incremental improvements to the
existing codebase which we can discuss and evaluate independently.
The existing activity bundle spec has a very simple manifest and
signature mechanism specified. Let's start by implementing that in
bundle-builder, and checking it in rainbow. Then we can discuss more
elaborate mechanisms.

I look forward to seeing your code for this. Please post it in
standard unified diff form to the security mailing list, with
'[PATCH]' in the subject line. Include me in the cc to ensure I see
it.
--scott
--
( http://cscott.net/ )
Loading...