Log of /trunk/Mix/TODO
Parent Directory
| 
Revision Log
Revision
378 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Modified
Fri Oct 18 20:42:35 2002 UTC
(10 years, 8 months ago)
by
rabbi
File length: 2015 byte(s)
Diff to
previous 311
,
to
selected 286
We've changed the client defaults to send messages immediately, rather
than pool messages. Also, I've removed some automatically generated files,
which never should have been in CVS in the first place.
Revision
286 -
(
view)
(
download)
(
annotate)
-
[selected]
Modified
Thu Sep 26 22:36:14 2002 UTC
(10 years, 8 months ago)
by
rabbi
File length: 2155 byte(s)
Diff to
previous 263
Updated to reflect recent changes.
Revision
220 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Modified
Fri Sep 6 21:04:16 2002 UTC
(10 years, 9 months ago)
by
rabbi
File length: 2091 byte(s)
Diff to
previous 219
,
to
selected 286
Updated documentation for {IN,OUT}DUMMYP, and to reflect changes in
remailer defaults.
Mixmaster now has a sanity-check on the number of dummy messages
generated automatically.
Fixed typos in mix.1 and Install.
Install now prompts before using a previously generated Makefile.
Revision
214 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Modified
Thu Sep 5 01:21:54 2002 UTC
(10 years, 9 months ago)
by
weaselp
File length: 2045 byte(s)
Diff to
previous 213
,
to
selected 286
Mixmaster keys now have creation and expiration date.
It is not secured by any crypto voodoo, it's only
informational for clients to decide which keys to
use should they have more.
- on the client side we do not show remailers (and
therefore not use them) if their key is expired.
- the remailer refuses to decrypt messages to keys
that expired one month ago or earlier.
- the remailer automatically creates new mixmaster
keys if the current one are about to expire or
already are expired.
- the latest key from secring.mix is written to
key.txt. It used to be the first one. Since
creation of new mix key appends the key, this
seemed sensible.
Revision
205 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Modified
Thu Aug 29 08:50:00 2002 UTC
(10 years, 9 months ago)
by
weaselp
File length: 1377 byte(s)
Diff to
previous 171
,
to
selected 286
When creating new OpenPGP keys, also set an expiry date. Key lifetime
defaults to 8 months but can be overriden by the KEYLIFETIME configuration
option.
We currently do not store the self signature and the keybinding (which hold
the expiry information in DSA keys) in the secret keyring. This is
unfortunate because we use the current KEYLIFETIME when recreating them
should the public keyring need to be rewritten. The solution is to store
them in the secret keyring (like GnuPG does) and not recreate them later
if we already have them.
Revision
165 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Modified
Thu Aug 22 04:01:16 2002 UTC
(10 years, 9 months ago)
by
weaselp
File length: 1428 byte(s)
Diff to
previous 164
,
to
selected 286
When sending type II messages interactivly you may now choose a middleman
remailer as the last hop in your chain (closes: #481244).
Revision
161 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Modified
Wed Aug 21 18:00:01 2002 UTC
(10 years, 10 months ago)
by
rabbi
File length: 1564 byte(s)
Diff to
previous 152
,
to
selected 286
Re-introduced the todo list with Reality.
Basically, if the install process is made friendly and saner, and we've
done real testing on the major platforms, I'm not too interested in holding
up 3.0 any longer. Everything else can be done in the point release.
Should we:
* leave AES support #ifdef'd out if OpenSSL 0.9.7 isn't released?
* support AES if the installed version of OpenSSL is 0.9.7beta3 or greater?
* include the necessary AES source from OpenSSL, as per the original patch?
I'm leaning toward option two, though we should still display the "this
version of OpenSSL is untested" message for 0.9.7. FWIW, 0.9.7beta3 has been
working fine for me on randseed.
Revision
152 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Modified
Wed Aug 21 07:03:37 2002 UTC
(10 years, 10 months ago)
by
rabbi
File length: 1213 byte(s)
Diff to
previous 150
,
to
selected 286
Currently, if Mixmaster is encrypting mail to multiple recipients, it does
not honor key preferences, and defaults to 3DES with no MDC.
It should choose the "most prefered" settings between the recipients, only
using 3DES/MDC if no other choice is available.
(We'll have to make some reasonable tie-breaking decisions, too -- for
instance, if one key lists AES,CAST and another lists CAST,AES -- which do
we take? I think we should have an internal "preference order" that is
used in these cases. I propose AES128,AES256,AES192,CAST5,3DES,IDEA,BLOW).
We'll want to use the MDC feature in all possible cases. Fixing this is
most important -- I'd be okay with using 3DES whenever we have multiple
recipients, as long as we could use MDC if they each advertised either
support for it in the features flag, or support for ciphers 7,8,9, or 10
(even though we don't support 10).
Hmm. Something else to check -- PGP 7.x can decrypt MDC when used with
3DES, right?
This form allows you to request diffs between any two revisions of this file.
For each of the two "sides" of the diff,
enter a numeric revision.
