end-to-end encoding self-test #406

New Issue

zooko · 2008-05-05T21:07:07Z

zooko commented

2008-05-05 21:07:07 +00:00

Figure out what is going on with Ben Laurie's Tahoe node on his FreeBSD-6 using the public Test Grid, make it reproducible if possible in the unit tests, fix it.

zooko added the

labels 2008-05-05 21:07:07 +00:00

zooko added this to the undecided milestone 2008-05-05 21:07:07 +00:00

zooko self-assigned this 2008-05-05 21:07:07 +00:00

zooko commented

2008-05-05 21:08:36 +00:00

Milestone 1.0.1 deleted

zooko added this to the 1.1.0 milestone 2008-05-05 21:08:36 +00:00

zooko commented

2008-05-05 23:02:26 +00:00

See tahoe-dev:

http://allmydata.org/pipermail/tahoe-dev/2008-May/000542.html

See tahoe-dev: <http://allmydata.org/pipermail/tahoe-dev/2008-May/000542.html>

warner commented

2008-05-06 17:28:16 +00:00

I'll read over the thread more closely and see if I can reproduce the problem locally.

I had first thought that it might just be the cap being corrupted, but that doesn't seem likely, given that the storage index is derived from the read-key.

I'll read over the thread more closely and see if I can reproduce the problem locally. I had first thought that it might just be the cap being corrupted, but that doesn't seem likely, given that the storage index is derived from the read-key.

warner commented

2008-05-06 20:05:24 +00:00

ah, ok, pycryptopp vs the stack. nevermind.

zooko commented

2008-05-09 19:14:23 +00:00

I'm working on adding "end to end" decryption, decoding, and parsing checks, i.e. in source:src/allmydata/test/test_encode.py upload some known-good, fixed ciphertext instead of encrypting, and likewise for SSK's and dirnodes.

zooko changed title from ~~data corruption (integrity failure) bug on Ben Laurie's machine~~ to end-to-end encoding self-test

2008-05-12 19:47:08 +00:00

zooko commented

2009-03-28 19:38:40 +00:00

The next step is to see what tahoe on Zandr's lenny-armel box does. The pycryptopp on that box seems to be giving incorrect decryption. Do the unit tests of tahoe on that box detect this misbehavior from pycryptopp?

zooko commented

2009-04-01 14:20:04 +00:00

Assigning this to Zandr in case he wants to look at it before the next time I circle around and log into his Linksys NAS box...

The hope is that when tahoe is used with a broken pycryptopp that gives wrong answers, that the tahoe unit tests fail.

Assigning this to Zandr in case he wants to look at it before the next time I circle around and log into his Linksys NAS box... The hope is that when tahoe is used with a broken pycryptopp that gives wrong answers, that the tahoe unit tests fail.

zooko commented

2009-04-07 15:59:12 +00:00

Some tests on Zandr's lenny-armel box do indeed fail, such as allmydata.test.test_system.SystemTest.test_upload_and_download_random_key. See the buildbot results: http://allmydata.org/buildbot/builders/Zandr%20Lenny-armel/builds/37/steps/test/logs/stdio . However, these are failing because encrypting a string and then decrypting the ciphertext doesn't yield the original string. A subtler bug (and one that we've had before in pycryptopp) is when encrypting the string and decrypting the ciphertext does yield the original string, but only when you use the same (buggy) code for both encryption and decryption. This ticket is to add a "test vector", for example a fixed ciphertext, computed with a known-good implementation of AES and then hardcoded into the test file as a string literal, and assert that when you decrypt that fixed ciphertext you get the correct plaintext.

Some tests on Zandr's lenny-armel box do indeed fail, such as `allmydata.test.test_system.SystemTest.test_upload_and_download_random_key`. See the buildbot results: <http://allmydata.org/buildbot/builders/Zandr%20Lenny-armel/builds/37/steps/test/logs/stdio> . However, these are failing because encrypting a string and then decrypting the ciphertext doesn't yield the original string. A subtler bug (and one that we've had before in pycryptopp) is when encrypting the string and decrypting the ciphertext does yield the original string, but only when you use the same (buggy) code for both encryption and decryption. This ticket is to add a "test vector", for example a fixed ciphertext, computed with a known-good implementation of AES and then hardcoded into the test file as a string literal, and assert that when you decrypt that fixed ciphertext you get the correct plaintext.

zooko added this to the 1.4.1 milestone 2009-04-07 15:59:12 +00:00

zooko commented

2009-12-13 05:17:09 +00:00

I'm making some progress on this, but it doesn't need to be done before Tahoe-LAFS v1.6.

zooko modified the milestone from 1.6.0 to eventually

2009-12-13 05:17:09 +00:00

davidsarah commented

2010-02-02 00:29:33 +00:00

Our tests are in general quite comprehensive, but this is a glaring omission.

tahoe-lafs modified the milestone from eventually to 1.7.0

2010-02-02 00:29:33 +00:00

tahoe-lafs added

critical

and removed

major

labels 2010-03-17 00:48:09 +00:00

zooko commented

2010-04-29 16:13:43 +00:00

I think we might have some tests to detect this now. Here's how to find out: mock out the AES class from pycryptopp (which is used in the [immutable upload]source:src/allmydata/immutable/upload.py@4164#L441, [mutable publish]source:src/allmydata/mutable/publish.py@4164#L400, [immutable download]source:src/allmydata/immutable/download.py@4248#L45, and [mutable retrieve]source:src/allmydata/mutable/retrieve.py@4126#L518).

zooko commented

2010-04-29 16:15:23 +00:00

…and then set the mock to encrypt-decrypt wrongly but consistently and then see if any tests fail.
Oh, and I guess this is also half of the job of writing the tests that we need! (If they aren't already there.) Shouldn't be too hard...

…and then set the mock to encrypt-decrypt wrongly but consistently and then see if any tests fail. Oh, and I guess this is also half of the job of writing the tests that we need! (If they aren't already there.) Shouldn't be too hard...

zooko modified the milestone from 1.7.0 to eventually

2010-05-16 23:39:51 +00:00

zooko commented

2012-03-29 16:01:59 +00:00

I'm demoting this from critical to major, since there are other urgent known-bugs (mostly in mutables) that are marked critical and this ticket, while certainly important, hasn't been touched in years.

I'm demoting this from `critical` to `major`, since there are other urgent known-bugs (mostly in mutables) that are marked `critical` and this ticket, while certainly important, hasn't been touched in years.

zooko added

major

and removed

critical

labels 2012-03-29 16:01:59 +00:00

Sign in to join this conversation.