mixmaster-devel Mailing List for Mixmaster (Page 76)
Brought to you by:
weaselp
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(65) |
Dec
(120) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(30) |
Feb
(17) |
Mar
(35) |
Apr
(17) |
May
(19) |
Jun
(4) |
Jul
(125) |
Aug
(187) |
Sep
(144) |
Oct
(171) |
Nov
(11) |
Dec
(109) |
2003 |
Jan
(61) |
Feb
(20) |
Mar
(22) |
Apr
(25) |
May
(57) |
Jun
(33) |
Jul
(24) |
Aug
(76) |
Sep
(13) |
Oct
(44) |
Nov
(43) |
Dec
(15) |
2004 |
Jan
(25) |
Feb
(2) |
Mar
(16) |
Apr
(63) |
May
(118) |
Jun
(13) |
Jul
|
Aug
|
Sep
(9) |
Oct
(1) |
Nov
(5) |
Dec
(1) |
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(9) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
2006 |
Jan
(3) |
Feb
(6) |
Mar
(4) |
Apr
|
May
|
Jun
(15) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(2) |
2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(6) |
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(14) |
Dec
(1) |
2008 |
Jan
(5) |
Feb
|
Mar
(31) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
|
2009 |
Jan
(3) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(10) |
Nov
(1) |
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Adam L. <ag...@li...> - 2001-11-06 19:46:26
|
> I'd agree that a minimum of 592 bits makes sense. We also need to consider > what the maximum should be. Do people really need 4096 bits? (I'd like to= say > yes, but it makes the structures larger). Of course we don't need to store the whole mix public key in the Forwarding Header at all, so it's a non-issue (expect to prevent silly resource hogging attacks on the sending mix). AGL --=20 Don't believe everything you hear or anything you say. |
From: Adam L. <ag...@li...> - 2001-11-06 19:42:08
|
On Tue, Nov 06, 2001 at 05:22:24PM +0200, dis...@ha... wrot= e: > Adam Langley wrote: > it should be: > II. RSASP x (not the RSASP b) is the RSA signing function using X's priva= te key Indeed, typo. > in "2. Crypto Handshake", II. > what is "Y a"? Sorry, Y_a is notiontion for A's public key (in this case, Alice's pubkey) > in "6. Messages" > why use IP, not hostname? No reason really. Infact hostname would be better. AGL --=20 The Street finds its own uses for technology. |
From: Adam L. <ag...@li...> - 2001-11-06 19:41:49
|
Opps, the Reply-To lines don't contain the list address. (can we fix that?) On Tue, Nov 06, 2001 at 12:18:21AM +0100, Max wrote: > EME-OAEP-ENCODE (Output length): >=20 > I don't understand the part about the EME-OAEP-ENCODE function. > You say it produces an output of 510 bytes? The OAEP specification says t= he > encoded message is atleast 2hLen+1 bytes. In our case hLen is 20 bytes=20 > (SHA-1), > so that would be a minimum of 41 bytes. A 520 bit modulus takes 65 bytes, > so we even have 23 bytes (184 bits) left.. no need to split it 8 times. >=20 > btw - If we'd use a minimum of 592 bits for the modulus n we could encode > 256 bits (a Rijndael key, or the output of sha-256,..). Mixing up bits and bytes in that one, sorry.=20 Warning to everyone out there: this is what too much stats does to you :) I'd agree that a minimum of 592 bits makes sense. We also need to consider what the maximum should be. Do people really need 4096 bits? (I'd like to s= ay yes, but it makes the structures larger). > VI) For Bob, Z =3D Ca**y mod n (not Cb**y mod n) > VII) For Alice, Z' =3D Cb**x mod n (not Ca**x mod n) >=20 > otherwise Z and Z' will not match.. yes, I have C_b and C_a the wrong way around. > -) Isn't 'g' a bit small (1024 bits)? > I found this site with a quick search at google right now: > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-02.t= xt > They use primes between 1536 and 8192 bits. Also look at > section 8 (security considerations). > As the initial handshake is only done once (unless connection is lost for > more then 3 hours) speed should not be an issue. Well, that g is a standard OpenPGP prime, but any of those groups will do. = How high do we need to go? 2048, 3072? 2048 should be ok, yes? > -) P in RSA-OAEP (d882 4474 7af6 3471 6233 8086 1450 c32d) > afaik P is optional/could be an empty octet string.. what > number is that ^^^? Yes, it's optional. But it doesn't hurt speedwise. That number if dd if=3D/dev/random bs=3D1 count=3D16 | hexdump > Section 6 (Messages): >=20 > -) Mix Headers > It seems like [IPv6 Addr][IPv6 Port] and [IPv4 Addr][IPv4 Port] > would only work for remailers with a static ip address. > Dialup and even many xDSL/Cable users/remailers have dynamic ip > addresses. > Maybe this should be changed to a string with some fixed maximum > lenght? This could either contain an IP address (for remailers with > static ips) or a hostname (something.dyndns.org for example) for > remailers with dynamic ip addresses. Yes, it should be a DNS name. > BIG endian: > currently most remailers run on little endian systems. why swap > every byte twice instead of using it as is (little endian)? Big endian is the simply the standard format for export. Is the CPU time ta= ken to shuffle bytes that bad? > please correct me if I've made a few stupid mistakes, too late > to think.. night! :) Nope, I think you're right AGL --=20 The Street finds its own uses for technology. |
From: <dis...@ha...> - 2001-11-06 15:52:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Len Sassaman wrote: > When processing the spool, a Mix server (or the Mix client) would > check to see if the next Mix server was listening. this works only if next Mix have fixed address (IP or hostname). > If no, the message > would process through SMTP in the ususal way. do we need to drop back to SMTP? it can try each XX minutes and if it is listening and send then. again only if next Mix have fixed address. or it can wait until next Mix connects (probably to send message) and then connect back to it and send spooled messages (or use the same connection?). this can be to send to dialup remailers that do not have fixed address. there still is problem how to send from dialup to dialup Mix... probably by randhop though one with fixed address. > The > receiving Mix only wants a secure connections and does not care about > the identity of the sender. If we want to prevent flooding the remailer should care who is the sender to: list admin - can you configure list so that Reply-To contains list's address __ Disastry http://disastry.dhs.org/remailer -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBO+frJTBaTVEuJQxkEQM/JACgrBIPcJwM/LSLMqYLUH1stbKP2AcAoMP7 BDoB+Q9IdYLZdYBST4ujLaG1 =co7z -----END PGP SIGNATURE----- |
From: <dis...@ha...> - 2001-11-06 15:21:42
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Adam Langley wrote: > As a discussion point to start things off here I'd like to throw the following > on the table > http://hawk.freenetproject.org/~agl/remix.pdf it should be: II. RSASP x (not the RSASP b) is the RSA signing function using X's private key in "2. Crypto Handshake", II. what is "Y a"? in "6. Messages" why use IP, not hostname? __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^--GPG for Win32 (supports loadable modules and IDEA) ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) http://disastry.dhs.org/remailer <----Dismix remailer stats -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBO+fjVTBaTVEuJQxkEQMMFQCg2JwDt2ioqOKMStzhaH3rq0KHRggAn22r S4T3rBQycwytJtq38N0okD6Z =7X/F -----END PGP SIGNATURE----- |
From: Len S. <ra...@qu...> - 2001-11-05 23:25:21
|
Here's Lance's previous email on this topic. (I don't think he has joined us on the list yet.) Scott Renfro was going to dig through the source that had this implemented in it. Scott, how goes it? ---------- Forwarded message ---------- Date: Mon, 17 Sep 2001 09:10:15 -0700 From: Lance M. Cottrell <lo...@an...> At one time I had developed a direct Mix to Mix link protocol. Unfortunately I never had the time to get the networking code fully debugged, so it was never released. I don't know if I still have the source. In brief, any mix operator could run a Mix daemon which would listen on a standard port (I think I used 22069). The IP or hostname of each server was stored in the key block. When processing the spool, a Mix server (or the Mix client) would check to see if the next Mix server was listening. If no, the message would process through SMTP in the ususal way. If it was listening, then an RSA authenticated DH key exchanges would be performed to secure the connection with forward security. One nice feature of the Mixmaster file format is that the fingerprint of the next remailer key is visible in the outgoing message. This allows the sending Mix to request a key from the receiving Mix, and to authenticate it against the fingerprint in the message. The receiving Mix only wants a secure connections and does not care about the identity of the sender. This also moves authentication to the original mix client, the Mix servers have no need to maintain up to date key chains or check with a CA. I would be happy to give more design philosophy to anyone working on this. -Lance At 11:31 PM -0400 9/14/01, Katherine wrote: >On Fri, 14 Sep 2001, Len Sassaman wrote: > >> I'd like to use this list to discuss implementation vulnerabilities in >> the mixmaster network, especially ones that are easy to exploit. The >> desired outcome would be patches to the software to correct these >> vulnerabilities. All mail sent to this list should be considered >> confidential. > >>From my limited experience and observations, the most common problem seems >to be floods/DoS. I believe it's Mike who came up with some nifty ways of >preventing this. And perhaps those things are best left at the MTA level, >though I'm sure some could be worked into Mix itself. > >My personal favorite is the reliance upon SMTP for inter-remailer >traffic. Not a vulnerability per se, but I believe a weakness. The >advantages it has is not reinventing the wheel: SMTP is obviously a robust >system. > >However: >1) MTAs like to log things. If you have nothing else on the system (or >just don't need logging) you can disable logging. But not everyone has >that ability. You also have the situation where the remop is not the only >person with access to the logs. > >2) Not everyone can run their own MTA. Someone could use this alternate >transfer method without bumping into email limits. > >Also, I think this would help the whitelist issue. If they transfer >method were authenticated, you would only need to check that you >recognize the key. So if someone were on a dynamic IP address you >wouldn't have to track them; the key would be the same. > >I guess it could also provide for "true" middleman remailers: ones that >only receive and send to/from other remailers. Someone who's ISP frowns >upon remailers (or that blocks SMTP) could run the server ona a high >port. They wouldn't even have to list their email address >anywhere. (this idea needs some work; just off the top of my head) > >Of course this does not neccesitate changes to the Mix code. SOmething >sitting between Mix and sendmail could decide whether a message should be >sent via SMTP or other means. A variation on that could allow for >Reliable (Win32) remailers to use the same system. > >Any, perhaps all that was off topic... :) > >Len, didn't you say you had some ideas about handling DoS? > >Katherine >(sitting home alone on a Friday :P ) Lance M. Cottrell lco...@an... Anonymizer, Inc. President Voice: (619) 725-3180 X304 Fax: (619) 725-3188 www.Anonymizer.com |
From: Max <lis...@te...> - 2001-11-05 23:16:42
|
At 18:27 05.11.2001 +0000, you wrote: Hello, >As a discussion point to start things off here I'd like to throw the following >on the table >http://hawk.freenetproject.org/~agl/remix.pdf > >Please don't take it as anything but a draft, and certainly anything in >Section 6 is just a sketch based on the old mix protocol. a few thoughts from the ex-Green admin. EME-OAEP-ENCODE (Output length): I don't understand the part about the EME-OAEP-ENCODE function. You say it produces an output of 510 bytes? The OAEP specification says the encoded message is atleast 2hLen+1 bytes. In our case hLen is 20 bytes (SHA-1), so that would be a minimum of 41 bytes. A 520 bit modulus takes 65 bytes, so we even have 23 bytes (184 bits) left.. no need to split it 8 times. btw - If we'd use a minimum of 592 bits for the modulus n we could encode 256 bits (a Rijndael key, or the output of sha-256,..). Section 2 (Handshake): I think you've got the formulas in step VI and VII mixed up a bit.. it should be like that: VI) For Bob, Z = Ca**y mod n (not Cb**y mod n) VII) For Alice, Z' = Cb**x mod n (not Ca**x mod n) otherwise Z and Z' will not match.. Section 7 (Constants): -) Isn't 'g' a bit small (1024 bits)? I found this site with a quick search at google right now: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-02.txt They use primes between 1536 and 8192 bits. Also look at section 8 (security considerations). As the initial handshake is only done once (unless connection is lost for more then 3 hours) speed should not be an issue. -) P in RSA-OAEP (d882 4474 7af6 3471 6233 8086 1450 c32d) afaik P is optional/could be an empty octet string.. what number is that ^^^? Section 6 (Messages): -) Mix Headers It seems like [IPv6 Addr][IPv6 Port] and [IPv4 Addr][IPv4 Port] would only work for remailers with a static ip address. Dialup and even many xDSL/Cable users/remailers have dynamic ip addresses. Maybe this should be changed to a string with some fixed maximum lenght? This could either contain an IP address (for remailers with static ips) or a hostname (something.dyndns.org for example) for remailers with dynamic ip addresses. BIG endian: currently most remailers run on little endian systems. why swap every byte twice instead of using it as is (little endian)? please correct me if I've made a few stupid mistakes, too late to think.. night! :) Max |
From: Adam L. <ag...@li...> - 2001-11-05 18:27:29
|
As a discussion point to start things off here I'd like to throw the follow= ing on the table http://hawk.freenetproject.org/~agl/remix.pdf Please don't take it as anything but a draft, and certainly anything in Section 6 is just a sketch based on the old mix protocol. AGL --=20 I never let my schooling get in the way of my education. |
From: Len S. <ra...@qu...> - 2001-11-04 22:09:40
|
Hey folks, There's a list set up at sourceforge for discussion of Mixmaster development. If you'd like to join, please jump right in. The main goal is to design and implement an inter-remailer protocol. Much of this work has already been done by Lance Cottrell. Bram Cohen and I have discussed some possible improvements, as well. I'll write up more about the existing ideas once the list is populated. List info is here: https://lists.sourceforge.net/lists/listinfo/mixmaster-devel --Len. -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson |