mixmaster-devel Mailing List for Mixmaster
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: Tom R. <to...@ri...> - 2016-02-09 15:07:19
|
On 8 February 2016 at 13:48, michellelaivee <mic...@wa...> wrote: > If the company's tech guru who runs our major email marketing server wants > to find out my ip address, will he be able to? I mean, not with a legal > court order, but just through his own dedicated hacking effort. It's unlikely hacking would work against random mixmaster servers. > And, if he did get a court order, is Mixmaster the style that is supposed to > be the hardest for him to go through the legal process of state after state > after jurisdiction after jurisdiction? If you are judicious in choosing your remailers, you can choose a bunch of countries to go through, besides just states. But either way, hacking or subpoenas, it won't matter as mixmaster servers would have to be explicitly configured to keep detailed logs - and no non-malicious admin would do that on purpose. Defeats the point. > I'm not breaking the law, but I want to forward a recent article to some > colleagues without the thought police at work being able to trace it back to > me. It's more likely (probable even) that you would be found out because you're "that person who's always talking about subverting the system and using these crazy anonymity tools." If you used your real email/name to send this message - that's a pointer. If you sent it from work, and they kept logs of access - you would be caught browsing mixmaster mailing lists, downloading the software, and connecting to a remailer to send the message. Those sorts of things. -tom |
From: Lance C. <lo...@ob...> - 2015-09-15 22:39:21
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I am very much in support of this proposal. The old code needs to be retired and the move to 4096 bits completed. -Lance Cottrell On 9/15/15, 12:45 PM, Steve Crook wrote: > Hi all, > > As many of you are probably aware, Mixmaster was forked in 2013 and > modified to support 4096 bit keys at the cost of reducing the potential > maximum hops from 20 to (worst case) 10. Other improvements were made, > either at the time or through ongoing development and Mixmaster now > supports AES_CTR encryption and HMAC authentication. The current packet > format is documented within the repository. > > Currently there are 27 publicly advertised Remailers, of which 10 are > running the forked code. Of these, 9 are advertising 4096 bit RSA keys. > I speculate that there are a number of reasons why more have not > migrated. These include: > > 1) The fork isn't recognised as the "official" version. > 2) The forked version isn't packaged for any major Linux distros. > 3) The Remailer is running on auto-pilot. > > I'd like to propose that the community addresses the first two on this > list by recognising the fork as the current, official Mixmaster version. > The repository resides on Github[1] and is publicly accessible. The > Debian package, currently maintained by Colin Tuckley can be migrated to > the forked code if this proposal is greeted favourably. Package > maintainers for other distros will probably follow in their own > timescales. > > In terms of client compatibility, along with Mixmaster itself, > Quicksilver and Omnimix are known to work with the forked Mixmaster. > Indeed, their current versions are compiled against it. Very old > clients, such as Jack B. Nymble and Private Idaho will not work but this > is nothing new, they still rely on Mixmaster versions that haven't been > revised in well over a decade. > > I'm posting this to:- > The Mixmaster Developers List (Sourceforge) > Remops Mailing List (http://lists.mixmin.net) > alt.privacy.anon-server (Usenet) > > If discussions are favourable, I propose that we adopt the forked Github > repository as the official Mixmaster version. > > Best wishes, > Steve Crook > > [1] https://github.com/merkinmuffley/mixmaster4096 > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Mixmaster-devel mailing list > Mix...@li... > https://lists.sourceforge.net/lists/listinfo/mixmaster-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJV+JprAAoJEKZcnJAGU1vU+i8H/iPSDIOjC44tgiFYlcHo5wS6 6EJ3HVBCGvWxbjrwSAxHAoPyNrxDJX4RJAH+3tGWW+Kq1PxRcDbb0sN9pdVVPLdq VETpg4uwjF1Mu1mQmM+TUFbxuSPSbtzR44eST+fAwBQJGjjNycyL5l/EvvdIvwJD O9WHbFOyr/KGMqTiqDZfUp3X1iI6+ObJf7v94PuxpHcIdGKBtxxBTuWAJB2FPWu+ 4hgTWZWjJpJQYt/FlumuS+w5zcgRiFBC5hswlz5WUIpzBTi1+lNKUAXVRQQNW98K gIeH57+dhrdhuXzvC6MROh66CMJjj7qsAygCk3Ess1d3snCziMuVjlwYBDUEde4= =OuAr -----END PGP SIGNATURE----- |
From: Steve C. <st...@mi...> - 2015-09-15 20:04:05
|
Hi all, As many of you are probably aware, Mixmaster was forked in 2013 and modified to support 4096 bit keys at the cost of reducing the potential maximum hops from 20 to (worst case) 10. Other improvements were made, either at the time or through ongoing development and Mixmaster now supports AES_CTR encryption and HMAC authentication. The current packet format is documented within the repository. Currently there are 27 publicly advertised Remailers, of which 10 are running the forked code. Of these, 9 are advertising 4096 bit RSA keys. I speculate that there are a number of reasons why more have not migrated. These include: 1) The fork isn't recognised as the "official" version. 2) The forked version isn't packaged for any major Linux distros. 3) The Remailer is running on auto-pilot. I'd like to propose that the community addresses the first two on this list by recognising the fork as the current, official Mixmaster version. The repository resides on Github[1] and is publicly accessible. The Debian package, currently maintained by Colin Tuckley can be migrated to the forked code if this proposal is greeted favourably. Package maintainers for other distros will probably follow in their own timescales. In terms of client compatibility, along with Mixmaster itself, Quicksilver and Omnimix are known to work with the forked Mixmaster. Indeed, their current versions are compiled against it. Very old clients, such as Jack B. Nymble and Private Idaho will not work but this is nothing new, they still rely on Mixmaster versions that haven't been revised in well over a decade. I'm posting this to:- The Mixmaster Developers List (Sourceforge) Remops Mailing List (http://lists.mixmin.net) alt.privacy.anon-server (Usenet) If discussions are favourable, I propose that we adopt the forked Github repository as the official Mixmaster version. Best wishes, Steve Crook [1] https://github.com/merkinmuffley/mixmaster4096 |
From: <li...@no...> - 2014-08-24 19:41:13
|
> Trevor points out that I can simply tag the subsequent hop and detect > it. It would look like this: > > Mix #1 (Attacker) wants to see if he is Hop #3 for this message. He > tags Header #4 (or if you're not counting the header encrypted to him, > Header #3) > Mix #2 (Honest) decrypts his header fine. > Mix #3 (Attacker) decrypts his header fine, but upon checking the > antitag for Header #4 sees that it's invalid. He knows he tagged the > message, so he's fairly sure that this is his tagged message. > > -tom > > [0] http://moderncrypto.org/mail-archive/messaging/2014/000527.html > Looks pretty hack-ish: > > * Compared to Sphinx [1] which can use curve25519 to encode headers > for 10 mixes in 384 bytes total, this format would use 10 KB, i.e. > it's about 30x less space efficient than it could be. > > * My guess is the "Anti-tag" hash only covers the next header, as you > mention and as described at [2], so fails to prevent tagging attacks > against later headers (e.g. see Sphinx and Mixminion which > integrity-protect all headers). > > * I assume this is RSA PKCS#1 encryption as per Mixmaster, which > should be avoided in new protocols. > > * The use of HMAC side-by-side with the HMAC key doesn't accomplish > anything vs a straightforward hash. > > * The presence of AES side-by-side with 3DES is weird. > > Side question, for you or anyone: Is this really the > "state-of-the-art" in real-world remailers? Is no-one working on > anything better? > > Trevor My aims in extending mixmaster last year were: - increase RSA key size and actually get it deployed - protect against the tagging attack described by Tom Ritter - add AES encryption - delete private keys after they have expired Since deployment only works if done gradually I catered for RSA key sizes of 1k, 2k, 3k and 4k - where the 1k behaviour is unchanged from the legacy code. I enabled a remailer to have multiple keys at once expecting a changeover period when a remailer might have a 1k and a 4k key. The 2k and 3k sizes were in case a lot of people wanted them and thought 4k was unnecessary. The legacy 3DES was left in because the code had to be there for the 1k case and adding AES over the unchanged 3DES should avoid arguments over whether the new version was stronger or weaker. The tagging defence was a response to https://crypto.is/blog/tagging_attack_on_mixmaster and I believe it works for that specific attack. I didn't look into the possibilities of tagging further into the chain - perhaps I should have but the work to deal with that is more because of the way it involves the position in the chain. HMAC involves running a hash twice similar to Practical Cryptography section 6.4.1 Cryptography Engineering section 5.4.1 and the sha256 now in use is better than the legacy MD5. That may be hackish but it's aimed at making mixmaster usable for longer - so no radical changes. |
From: Tom R. <to...@ri...> - 2014-08-24 03:33:29
|
I'd like to revive this thread, sorry. Originally it was about the anti-tagging mechanism and moving to 4096 bit keys. Originally, I thought that the anti-tagging mechanism was valid, but after discussing it with some other folks [0], I don't think it is. Specifically: If I'm correct the anti-tagging mechanism asserts the validity of the _next_ hop, and the payload. But it only asserts the validity of the next hop, not the hops after the next hop. Trevor points out that I can simply tag the subsequent hop and detect it. It would look like this: Mix #1 (Attacker) wants to see if he is Hop #3 for this message. He tags Header #4 (or if you're not counting the header encrypted to him, Header #3) Mix #2 (Honest) decrypts his header fine. Mix #3 (Attacker) decrypts his header fine, but upon checking the antitag for Header #4 sees that it's invalid. He knows he tagged the message, so he's fairly sure that this is his tagged message. (I'm not writing a paper here, so I haven't thought about how he could tag it in such a way that he could undo the tag and be certain it was his tag, I'm just looking at it from an error perspective. ) Looking at the code, I don't think one would be able to tag a 3-hop chain, because one would need to tag Hop #4 (which doesn't have a valid antitag) OR one would need to tag the payload (which is protected at Hop #2). Likewise, one is not able to tag to determine if you're the exit remailer (because of the same Hop#4 problem). -tom [0] http://moderncrypto.org/mail-archive/messaging/2014/000527.html |
From: Steve C. <st...@mi...> - 2014-08-23 19:59:22
|
On Sat, Aug 23, 2014 at 06:15:57PM +0100, li...@no... wrote: > Steve Crook <steve mixmin.net> > > Sorry for not replying to this as my spam detection was too severe. No problem, your comments in the code made it easy to decipher once I motivated myself to figure it out. > > After studying the mixmaster-3.0.2 code, I think I can answer some of > > these questions myself. For the above: No padding is applied to the RSA > > data so the subsequent fields are at variable positions within the > > header. > > Agreed: encrypted RSA data size depends on key size. > > > The Anti-tag is calculated on 2*512 Byte header blocks but in a scenario > > where the exit remailer uses a 1024bit key, there is only 512 Bytes of > > header data. I've not entirely sure how this scenario is handled. If > > the hmac is calculated on just the 512 Bytes of the exit header then a > > remailer can determine when it's the penultimate member of the chain. > > The aim is a remailer cannot tell where it is in the chain (unless it's the > exit) and the header HMAC is always calculated over 1024 bytes (there is > always onion-packed data even if it's random rather than meaningful header > and the HMAC is just to check it wasn't changed). In the case I think you mean > where the full chain is used and the last 2 hops are 4096,1024 then 512 bytes > of the input to the HMAC will be read from the message body. Ah, that makes sense now, thanks. I will need to tweak my client implementation to handle that scenario. > > There is a bug in the implementation of the AES encrypt/decrypt functions > > but it impacts both directions in an identical manner so they work > > together. The spec calls for an identical IV to be used in all three > > AES encrypt/decrypt functions but the implementation uses a unique IV > > for each. This happens because the OpenSSL CRYPTO_cfb128_encrypt > > function modifies the IV during each operation. > > > > It would probably be better to derive three IVs, one for each AES key > > but this would now break backward compatibility. > > I was assuming since different keys are used nobody cares if the IV is shared. > And the update to the IV is unintended - a buglet. It's generally considered bad to reuse an IV but, as you say, with different keys, I'm not sure if that matters. The changing IV doesn't matter in Mixmaster as it changes identically during encrypt and decrypt operations. It's more of a headache for writing other clients though: I'm trying to unpick the CRYPTO_cfb128_encrypt function in OpenSSL to figure out how the IV mutates so I can reproduce the behaviour. The writer of that function operates on a different level to me so progress is slow! :) > If we were to make an incompatible change further things that might be > done are: > - potentially longer chains (someone has been complaining about the limit > of 10 hops with large keys) Yes, I tried to avoid that debate! I think 10 hops is plenty. If you made it 20, somebody would want 30. :) > - encrypt only an unpadded large random value under RSA and derive all other > per-hop random values from it (Cryptography Engineering section 12.6) Or use a RSA to encrypt a single 3DES or AES key and put all the sensitive stuff in the encrypted header. > - drop 3DES Maybe replace that with AES and RSA with ECC. The second would save a shed-load of Bytes. > I suspect incompatible changes are best reserved for a complete new scheme > such as https://github.com/nmathewson/mixminion . I'd love to see mixminion revived. Unfortunately, while I can understand and, to some extent, implement the Mixmaster spec, the maths in Mixminion is beyond my grasp. |
From: <li...@no...> - 2014-08-23 17:41:13
|
Steve Crook <steve mixmin.net> Sorry for not replying to this as my spam detection was too severe. > After studying the mixmaster-3.0.2 code, I think I can answer some of > these questions myself. For the above: No padding is applied to the RSA > data so the subsequent fields are at variable positions within the > header. Agreed: encrypted RSA data size depends on key size. > The Anti-tag is calculated on 2*512 Byte header blocks but in a scenario > where the exit remailer uses a 1024bit key, there is only 512 Bytes of > header data. I've not entirely sure how this scenario is handled. If > the hmac is calculated on just the 512 Bytes of the exit header then a > remailer can determine when it's the penultimate member of the chain. The aim is a remailer cannot tell where it is in the chain (unless it's the exit) and the header HMAC is always calculated over 1024 bytes (there is always onion-packed data even if it's random rather than meaningful header and the HMAC is just to check it wasn't changed). In the case I think you mean where the full chain is used and the last 2 hops are 4096,1024 then 512 bytes of the input to the HMAC will be read from the message body. > There is a bug in the implementation of the AES encrypt/decrypt functions > but it impacts both directions in an identical manner so they work > together. The spec calls for an identical IV to be used in all three > AES encrypt/decrypt functions but the implementation uses a unique IV > for each. This happens because the OpenSSL CRYPTO_cfb128_encrypt > function modifies the IV during each operation. > > It would probably be better to derive three IVs, one for each AES key > but this would now break backward compatibility. I was assuming since different keys are used nobody cares if the IV is shared. And the update to the IV is unintended - a buglet. If we were to make an incompatible change further things that might be done are: - potentially longer chains (someone has been complaining about the limit of 10 hops with large keys) - encrypt only an unpadded large random value under RSA and derive all other per-hop random values from it (Cryptography Engineering section 12.6) - drop 3DES I suspect incompatible changes are best reserved for a complete new scheme such as https://github.com/nmathewson/mixminion . |
From: Steve C. <st...@mi...> - 2014-08-23 15:49:56
|
On Wed, Aug 20, 2014 at 11:59:49AM +0100, Steve Crook wrote: > Hi, > > I'm trying to code a Mixmaster client with compatibility to the new 1024 > Byte header format used in Mixmaster-3.0.2. I'd appreciate a little > help in understanding the process for producing the new header. > > As I understand it, the header format is:- > > Public key ID [ 16 bytes] > Length of RSA-encrypted data [ 1 byte ] > RSA-encrypted data [ 256/384/512 bytes ] > 3DES Session Key [ 24 bytes ] > Random HMAC Key [ 64 bytes ] > HMAC hash (Anti-tag) [ 32 bytes ] > HMAC hash (Body) [ 32 bytes ] > HMAC hash (328 Byte Enc Head) [ 32 bytes ] > AES Pre Key [ 32 bytes ] > ?Padding? > 3DES Initialization vector [ 8 bytes] > Encrypted header part [ 328 bytes] > Padding [ n bytes] > ----------------------------------------- > Total [ 1024 bytes] > > First question: Is the RSA-encrypted section always padded to 512 Bytes > or is it variable depending on the RSA key size? To put it another way, > is the position of the 3DES IV always 529 Bytes in, or is it floating? After studying the mixmaster-3.0.2 code, I think I can answer some of these questions myself. For the above: No padding is applied to the RSA data so the subsequent fields are at variable positions within the header. > HMAC Anti-Tag:- > I believe this is a hash of the subsequent 512 Byte header *after > encryption*. This implies that the next header must already have been > encrypted using the 3DES Key and IV from the current 328 Byte component. > Also, what goes in here for an Exit type header? The field is populated with random data for an exit header. The Anti-tag is calculated on 2*512 Byte header blocks but in a scenario where the exit remailer uses a 1024bit key, there is only 512 Bytes of header data. I've not entirely sure how this scenario is handled. If the hmac is calculated on just the 512 Bytes of the exit header then a remailer can determine when it's the penultimate member of the chain. > HMAC Body:- > As above, to generate the HMAC Body, the body must already be encrypted > using the current 328 Byte block. > > HMAC 328:- > This is a hash of the 328 Byte block, *after* 3DES encryption. All the above HMACS are calculated after 3DES and AES encryption. > AES Pre Key:- > From the packet_layout document: > "The aes_pre_key is used together with HMAC-SHA256 to generate the 3 > AES keys for the body, future headers and the current header data of > size 328." > I'm struggling to understand this bit. Is this a salt that's used in > conjunction with the previous HMACs to generate three AES keys? Is > there an IV associated with each of them? The 3 keys and the IV are derived from an HMAC function on a static plaintext concatenated with the HMAC key. The static texts being: body-crypt tte-crypt header-crypt aes-iv There is a bug in the implementation of the AES encrypt/decrypt functions but it impacts both directions in an identical manner so they work together. The spec calls for an identical IV to be used in all three AES encrypt/decrypt functions but the implementation uses a unique IV for each. This happens because the OpenSSL CRYPTO_cfb128_encrypt function modifies the IV during each operation. It would probably be better to derive three IVs, one for each AES key but this would now break backward compatibility. Steve |
From: Colin T. <co...@tu...> - 2014-08-20 16:03:49
|
On 20/08/14 15:47, Marco A. Calamari wrote: > just and idea, if worthing discussing it. > > did the author of extensions considered to publish an enhanced > version of RFC draft Len filed ages ago or a new draft? > > http://tools.ietf.org/html/draft-sassaman-mixmaster-03 > > Keep up with the good work! Marco Marco, or whoever - please only post to this list from a subscribed email address. Messages from non-subscribed addresses are held for moderation which causes delay and makes work for the moderators (i.e. me). Colin -- Colin Tuckley | +44(0)1223 830814 | PGP/GnuPG Key Id Debian Developer | +44(0)7799 143369 | 0x38C9D903 Misfortune: The kind of fortune that never misses. |
From: Marco A. C. <mar...@ma...> - 2014-08-20 14:47:24
|
On Wed, 2014-08-20 at 11:59 +0100, Steve Crook wrote: > Hi, > > I'm trying to code a Mixmaster client with compatibility to the new 1024 > Byte header format used in Mixmaster-3.0.2. I'd appreciate a little > help in understanding the process for producing the new header. > > As I understand it, the header format is:- > > Public key ID [ 16 bytes] Hi, just and idea, if worthing discussing it. did the author of extensions considered to publish an enhanced version of RFC draft Len filed ages ago or a new draft? http://tools.ietf.org/html/draft-sassaman-mixmaster-03 Keep up with the good work! Marco -- Marco A.Calamari - Board Member mar...@lo... +39.347.8530279 HERMES - Center for Transparency and Digital Human Rights Not for Profit association - Via Aretusa 34, IT-20129 Milan, Italy t. +39-02-87186005 (voicemail) f. +39-02-87162573 TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254 w. http://logioshermes.org | m. in...@lo... |
From: Steve C. <st...@mi...> - 2014-08-20 11:16:54
|
Hi, I'm trying to code a Mixmaster client with compatibility to the new 1024 Byte header format used in Mixmaster-3.0.2. I'd appreciate a little help in understanding the process for producing the new header. As I understand it, the header format is:- Public key ID [ 16 bytes] Length of RSA-encrypted data [ 1 byte ] RSA-encrypted data [ 256/384/512 bytes ] 3DES Session Key [ 24 bytes ] Random HMAC Key [ 64 bytes ] HMAC hash (Anti-tag) [ 32 bytes ] HMAC hash (Body) [ 32 bytes ] HMAC hash (328 Byte Enc Head) [ 32 bytes ] AES Pre Key [ 32 bytes ] ?Padding? 3DES Initialization vector [ 8 bytes] Encrypted header part [ 328 bytes] Padding [ n bytes] ----------------------------------------- Total [ 1024 bytes] First question: Is the RSA-encrypted section always padded to 512 Bytes or is it variable depending on the RSA key size? To put it another way, is the position of the 3DES IV always 529 Bytes in, or is it floating? HMAC Anti-Tag:- I believe this is a hash of the subsequent 512 Byte header *after encryption*. This implies that the next header must already have been encrypted using the 3DES Key and IV from the current 328 Byte component. Also, what goes in here for an Exit type header? HMAC Body:- As above, to generate the HMAC Body, the body must already be encrypted using the current 328 Byte block. HMAC 328:- This is a hash of the 328 Byte block, *after* 3DES encryption. AES Pre Key:- From the packet_layout document: "The aes_pre_key is used together with HMAC-SHA256 to generate the 3 AES keys for the body, future headers and the current header data of size 328." I'm struggling to understand this bit. Is this a salt that's used in conjunction with the previous HMACs to generate three AES keys? Is there an IV associated with each of them? Many thanks, Steve |
From: <li...@no...> - 2013-11-14 07:11:35
|
Version 3.0.2a is a small change from 3.0.2 where the default key size is now 4096 and in the stats processing a buffer is checked to ensure it is initialised before use. http://www.zen19351.zen.co.uk/mixmaster302/ mixmaster-3.0.2a.tar.gz SHA256(mixmaster-3.0.2a.tar.gz)= 1f921039148d84fb3c89bbf9a8e1637cfbf3d0e02cb0612df67f50ea569884b9 diff mixmaster-3.0.2/Src/stats.c mixmaster-3.0.2a/Src/stats.c 242c242 < if ((rs=mix_openfile(RSATEXTFILE, "r")) != NULL) { --- > if (b && (rs=mix_openfile(RSATEXTFILE, "r")) != NULL) { |
From: <li...@no...> - 2013-10-31 00:22:54
|
Lance Cottrell <loki obscura.com> > I like to avoid asking users to think too much. > It would be ideal if there were some kind of timer or something, so it = > could get widely deployed before starting to be used. stage 1 We have to start with agreement on the change in key size. Can everybody on these lists test and examine the new s/w and either agree to use it in all mixmaster remailer installations or else state their objections here? By end November? (If anyone runs a remailer on Windows I'd be interested in the result of testing there as I haven't done any.) stage 2 Remailers upgrade the s/w but do not publish large keys yet. Then distribute the new s/w - from every site we can manage that currently has mixmaster s/w for download. And run a publicity campaign saying people need the new s/w ready for an upgrade in key size coming soon. Because of the anonymous user base this has to be a broadcast on mailing lists, newsgroups, blogs and forums. Publicity will include the error message shown by old s/w used with large keys so that anyone who misses the upgrade and googles the error message will catch on. (Throughout December?) Up to this point there's been no change in the formatting/crypto behaviour outside of testing because no large keys are in use. stage 3 At an agreed time all remailers generate 4096-bit keys and all the places publishing keys make sure to distribute them. Expiry of all 1024-bit keys follows. One week after new year? |
From: Lance C. <lo...@ob...> - 2013-10-30 16:29:50
|
I like to avoid asking users to think too much. It would be ideal if there were some kind of timer or something, so it could get widely deployed before starting to be used. -Lance -- Lance Cottrell lo...@ob... On Oct 29, 2013, at 5:16 PM, li...@no... wrote: > Lance Cottrell <loki obscura.com> writes: > >> In practice, no one uses more than a few hops for real >> messages. I suspect that 5 is the realistic upper limit to >> ensure reasonable delivery time and reliability. I really >> went over the top in using 20 header blocks. > > Good thing too provided the cost was acceptable. If you'd > used 6 hops then halving it would get 3. > >> Roll out will be a key. One does not want client software that >> only has one or two servers through which it could route, >> nor would one want to be one of only a few few users of the >> new key size, since that would be easily tracked as well. > > Ease of deployment is why I've arranged my code as I have. Remailers > and clients don't need to update at the same time and anyone with the > new client remains able to use all the remailers. > > You can always pick a 1024 remailer as a first hop if you don't want > to be recognised as a user of the new software (assuming you downloaded > it undetected). |
From: <li...@no...> - 2013-10-30 00:17:04
|
Lance Cottrell <loki obscura.com> writes: > In practice, no one uses more than a few hops for real > messages. I suspect that 5 is the realistic upper limit to > ensure reasonable delivery time and reliability. I really > went over the top in using 20 header blocks. Good thing too provided the cost was acceptable. If you'd used 6 hops then halving it would get 3. > Roll out will be a key. One does not want client software that > only has one or two servers through which it could route, > nor would one want to be one of only a few few users of the > new key size, since that would be easily tracked as well. Ease of deployment is why I've arranged my code as I have. Remailers and clients don't need to update at the same time and anyone with the new client remains able to use all the remailers. You can always pick a 1024 remailer as a first hop if you don't want to be recognised as a user of the new software (assuming you downloaded it undetected). |
From: <li...@no...> - 2013-10-29 23:58:57
|
Steve Crook <steve mixmin.net> writes: > Coincidentally we appear to have arrived at very similar solutions. There was a certain obviousness about the main thrust of our designs. > Encrypted Header (384 Bytes): > [ Packet ID 16 bytes ] > [ AES key 32 bytes ] > [ Packet type identifier 1 byte ] > [ Packet Info 256 bytes ] > [ Timestamp 2 bytes ] > [ Padding 13 bytes ] > [ SHA2-512 Message digest 64 bytes ] > > Header (1024 Bytes): > [ Public key ID 16 bytes ] > [ Length of RSA-encrypted data 2 bytes ] > [ RSA-encrypted session key 512 bytes ] > [ Initialization vector 16 bytes ] > [ Encrypted header part 384 bytes ] > [ Padding 30 bytes ] > [ SHA2-512 Message digest 64 bytes ] I see you've moved message digests to predictable positions at the end of each block to avoid the current mess where you need to somewhat use the block before you can check it matches the digest. I doubt 65536 different public keys sizes are needed. My guess is 4096 (only) is good for the near term and then the best recommendation will be some EC - but which one nobody may know for a while. Who knows whether in a couple of years NIST and DJB might endorse a few of the same curves? With a new incompatible alternative you have options such as a protocol version field to indicate what is coming later in the packet. > This is currently only something I'm playing with so it should be easy > to modify it to concur with your specification. I don't think an alternative needs to follow my spec which is a minimal change for easy migration. If you're aiming for a new codebase and no more 3DES then you have a new start. I think the worthwhile points to lift are: - On intermediate hops require an integrity check on the following hop as explained on Ritter's blog. - Use hashes iterated twice (as reccomended by Schneier). The style of iterations I've used is HMAC. - Encrypt under RSA data that is not a symmetric key itself but is something that hashes to the symmetric key. Then if a break against RSA leaks half your bits the search space has not been much reduced. (I think I read that in Schneier too.) - If the first design leaves space inside the RSA-encrypted data it may be useful later. > I'm also looking at using HTTP as a transport instead of SMTP. The > justification for this being that HTTP is used extensively on the Tor > network. This should make it very easy to run remailers as Tor Location > Hidden Services. HTTP(S) typically has small requests and large replies. That suggests a change from an SMTP-like model to a POP3-like model where each node would query other nodes with "any messages for me? show me one". To do this each node would have to know where to receive from (information that starts out in the client that prepares the onion packaging). So some way of introducing nodes to each other is required. |
From: Lance C. <lo...@ob...> - 2013-10-29 16:57:06
|
This is an excellent proposal. In practice, no one uses more than a few hops for real messages. I suspect that 5 is the realistic upper limit to ensure reasonable delivery time and reliability. I really went over the top in using 20 header blocks. Roll out will be a key. One does not want client software that only has one or two servers through which it could route, nor would one want to be one of only a few few users of the new key size, since that would be easily tracked as well. -Lance -- Lance Cottrell lo...@ob... On Oct 29, 2013, at 2:34 AM, Steve Crook <st...@mi...> wrote: > On Tue, Oct 29, 2013 at 02:15:09AM +0000, li...@no... wrote: >> Mixmaster has long used 1024-bit RSA with a packet format that allows >> a maximum of 20 hops; each encrypted with a different RSA key. The >> data for each hop occupies 512 bytes. >> >> Given the declining protection offered by a key size from the 1990s I >> decided to investigate adapting mixmaster to use 2048-bit keys (each >> in a larger header block) at a cost of reducing the longest chain to >> 10 hops. >> >> It turned out possible to exceed this goal. By using a header of >> 1024 bytes (max 10 hops) new code can use key sizes of 2048, 3072 >> and 4096 for RSA. E.g. 10 hops of 4096; or 2 of 1024 and 9 of 4096. >> (Key generation might be "mixmaster -G --size=4096 --lifetime=90".) >> The default size in the new code is 2048 bits. > Coincidentally we appear to have arrived at very similar solutions. > I've also got a working Mixmaster alternative that uses 10 headers of > 1024 bytes each. This adds support for up to 4096-bit RSA keys and > maintains the same overall packet size of 20480 bytes. > > My spec is: > > Packet Info (256 Bytes):- > Packet type 0 (intermediate hop): > [ 9 Initialization vectors 144 bytes ] > [ Next address 112 bytes ] > > Packet type 1 (final hop): > [ Chunk number 1 byte ] > [ Number of chunks 1 byte ] > [ Message ID 16 bytes ] > [ Initialization vector 16 bytes ] > [ Padding 222 bytes ] > > Mixmaster currently has three Packet Types but I couldn't see the point > of seperating Exit and Chunked Exit when Exit can just be a single Chunk. > > Encrypted Header (384 Bytes): > [ Packet ID 16 bytes ] > [ AES key 32 bytes ] > [ Packet type identifier 1 byte ] > [ Packet Info 256 bytes ] > [ Timestamp 2 bytes ] > [ Padding 13 bytes ] > [ SHA2-512 Message digest 64 bytes ] > > Header (1024 Bytes): > [ Public key ID 16 bytes ] > [ Length of RSA-encrypted data 2 bytes ] > [ RSA-encrypted session key 512 bytes ] > [ Initialization vector 16 bytes ] > [ Encrypted header part 384 bytes ] > [ Padding 30 bytes ] > [ SHA2-512 Message digest 64 bytes ] > > Payload: > [ Length 2 bytes ] > [ SHA2-512 Message Digest 64 bytes ] > [ Content 10174 bytes ] > > This is currently only something I'm playing with so it should be easy > to modify it to concur with your specification. > > I'm also looking at using HTTP as a transport instead of SMTP. The > justification for this being that HTTP is used extensively on the Tor > network. This should make it very easy to run remailers as Tor Location > Hidden Services. > >> Actions: >> 1. To review and discuss the code please use Mix...@li... >> (still a useful place to hold discussion although the SF maintainers are inactive ). >> 2. To discuss testing and deployment use Re...@li... (it would be helpful >> to have some short-term test remailers even if they were not to remain long term.) >> Some traffic may be relevant on both those lists and maybe also cry...@me... . >> 3. Development of a more advanced remailer needs a lead maintainer: >> mix...@se... >> http://mixminion.net/ >> https://github.com/nmathewson/mixminion >> 4. Restore freedom to the galaxy! >> >> Code location: >> http://www.zen19351.zen.co.uk/mixmaster302/mixmaster-3.0.2.tar.gz >> SHA256(mixmaster-3.0.2.tar.gz)= a88b93ea21c42ff588db6bc506b3e6eea4e8eb666d5a90beb1dd785b7e0920ed > Thanks very much for your efforts, I'll take a look and provide some > feedback. > _______________________________________________ > Remops mailing list > Re...@li... > http://lists.mixmin.net/mailman/listinfo/remops |
From: Steve C. <st...@mi...> - 2013-10-29 09:51:41
|
On Tue, Oct 29, 2013 at 02:15:09AM +0000, li...@no... wrote: > Mixmaster has long used 1024-bit RSA with a packet format that allows > a maximum of 20 hops; each encrypted with a different RSA key. The > data for each hop occupies 512 bytes. > > Given the declining protection offered by a key size from the 1990s I > decided to investigate adapting mixmaster to use 2048-bit keys (each > in a larger header block) at a cost of reducing the longest chain to > 10 hops. > > It turned out possible to exceed this goal. By using a header of > 1024 bytes (max 10 hops) new code can use key sizes of 2048, 3072 > and 4096 for RSA. E.g. 10 hops of 4096; or 2 of 1024 and 9 of 4096. > (Key generation might be "mixmaster -G --size=4096 --lifetime=90".) > The default size in the new code is 2048 bits. Coincidentally we appear to have arrived at very similar solutions. I've also got a working Mixmaster alternative that uses 10 headers of 1024 bytes each. This adds support for up to 4096-bit RSA keys and maintains the same overall packet size of 20480 bytes. My spec is: Packet Info (256 Bytes):- Packet type 0 (intermediate hop): [ 9 Initialization vectors 144 bytes ] [ Next address 112 bytes ] Packet type 1 (final hop): [ Chunk number 1 byte ] [ Number of chunks 1 byte ] [ Message ID 16 bytes ] [ Initialization vector 16 bytes ] [ Padding 222 bytes ] Mixmaster currently has three Packet Types but I couldn't see the point of seperating Exit and Chunked Exit when Exit can just be a single Chunk. Encrypted Header (384 Bytes): [ Packet ID 16 bytes ] [ AES key 32 bytes ] [ Packet type identifier 1 byte ] [ Packet Info 256 bytes ] [ Timestamp 2 bytes ] [ Padding 13 bytes ] [ SHA2-512 Message digest 64 bytes ] Header (1024 Bytes): [ Public key ID 16 bytes ] [ Length of RSA-encrypted data 2 bytes ] [ RSA-encrypted session key 512 bytes ] [ Initialization vector 16 bytes ] [ Encrypted header part 384 bytes ] [ Padding 30 bytes ] [ SHA2-512 Message digest 64 bytes ] Payload: [ Length 2 bytes ] [ SHA2-512 Message Digest 64 bytes ] [ Content 10174 bytes ] This is currently only something I'm playing with so it should be easy to modify it to concur with your specification. I'm also looking at using HTTP as a transport instead of SMTP. The justification for this being that HTTP is used extensively on the Tor network. This should make it very easy to run remailers as Tor Location Hidden Services. > Actions: > 1. To review and discuss the code please use Mix...@li... > (still a useful place to hold discussion although the SF maintainers are inactive ). > 2. To discuss testing and deployment use Re...@li... (it would be helpful > to have some short-term test remailers even if they were not to remain long term.) > Some traffic may be relevant on both those lists and maybe also cry...@me... . > 3. Development of a more advanced remailer needs a lead maintainer: > mix...@se... > http://mixminion.net/ > https://github.com/nmathewson/mixminion > 4. Restore freedom to the galaxy! > > Code location: > http://www.zen19351.zen.co.uk/mixmaster302/mixmaster-3.0.2.tar.gz > SHA256(mixmaster-3.0.2.tar.gz)= a88b93ea21c42ff588db6bc506b3e6eea4e8eb666d5a90beb1dd785b7e0920ed Thanks very much for your efforts, I'll take a look and provide some feedback. |
From: <li...@no...> - 2013-10-29 02:15:20
|
Mixmaster has long used 1024-bit RSA with a packet format that allows a maximum of 20 hops; each encrypted with a different RSA key. The data for each hop occupies 512 bytes. Given the declining protection offered by a key size from the 1990s I decided to investigate adapting mixmaster to use 2048-bit keys (each in a larger header block) at a cost of reducing the longest chain to 10 hops. It turned out possible to exceed this goal. By using a header of 1024 bytes (max 10 hops) new code can use key sizes of 2048, 3072 and 4096 for RSA. E.g. 10 hops of 4096; or 2 of 1024 and 9 of 4096. (Key generation might be "mixmaster -G --size=4096 --lifetime=90".) The default size in the new code is 2048 bits. The RSA encryption transferred a 3DES key of 24 bytes and otherwise contained a lot of free space. Taking advantage of this space to transfer extra data without growing the packets enabled further progress. When using the larger RSA keys (2048 and up) the symmetric crypto of 3DES CBC is augmented by adding AES-256 CFB on top of it. And three parts of the data are covered by HMAC-SHA256 (in the order encrypt then MAC). - the body which previously had no protection - the current header block which had only MD5 - the next header block to prevent a tagging attack (see footnotes) When using 1024-bit RSA these new features are not used so as to keep compatibility with older software. Stats are kept of the RSA key sizes used to help operators monitor uptake of larger keys and assess when 1024-bit keys can be discontinued. Actions: 1. To review and discuss the code please use Mix...@li... (still a useful place to hold discussion although the SF maintainers are inactive ). 2. To discuss testing and deployment use Re...@li... (it would be helpful to have some short-term test remailers even if they were not to remain long term.) Some traffic may be relevant on both those lists and maybe also cry...@me... . 3. Development of a more advanced remailer needs a lead maintainer: mix...@se... http://mixminion.net/ https://github.com/nmathewson/mixminion 4. Restore freedom to the galaxy! Code location: http://www.zen19351.zen.co.uk/mixmaster302/mixmaster-3.0.2.tar.gz SHA256(mixmaster-3.0.2.tar.gz)= a88b93ea21c42ff588db6bc506b3e6eea4e8eb666d5a90beb1dd785b7e0920ed Further reading: http://www.freehaven.net/anonbib/cache/mixmaster-spec.txt https://crypto.is/blog/packet_formats_1 https://crypto.is/blog/tagging_attack_on_mixmaster http://www.nsa.gov/business/programs/elliptic_curve.shtml |
From: <li...@no...> - 2013-10-21 10:46:05
|
http://www.zen19351.zen.co.uk/mixmaster/ |
From: <li...@no...> - 2013-10-11 20:37:39
|
A patch is attached. 1. Old secret keys are to be deleted automatically after expiry. (I was surprised to see that was not already happening. An adversary capturing your old keyfile seems able to decrypt old messages.) This patch overwrites the old file after replacing it with a new one that no longer contains the expired keys. I encourage operators to check whether they have unwanted secret keys still present on their systems. 2. A new command-line option enables you to set a key lifetime. mixmaster -G --lifetime=28 If you do not specify the lifetime (in days) the default is used. If a remailer has a long-term key (such as 1 year) as well as generating a short-term key each day then someone who wanted to could choose a key that was close to expiry and less at risk of disclosure. (Automation of that would require changes in the client.) (Plus a greater volume of 1024-bit keys is more work for anyone factoring the remailer keys.) 3. A new file contains all public keys for your remailer. Keep up the good work. |
From: <li...@no...> - 2013-10-10 22:47:34
|
I have been thinking about the keys used by mixmaster and attach a patch for your consideration. 1. Old secret keys are to be deleted automatically after expiry. (I was surprised to see that was not already happening. An adversary capturing your old keyfile seems able to decrypt old messages.) This patch does not deal with secure deletion of the old file which I hope to address later. 2. A new command-line option enables you to set a key lifetime. mixmaster -G --lifetime=28 If you do not specify the lifetime (in days) the default is used. If a remailer has a long-term key (such as 1 year) as well as generating a 7-day key each day then someone who wanted to could choose a key that was close to expiry and less at risk of disclosure. (Automation of that would require changes in the client.) (Plus a greater volume of 1024-bit keys is more work for anyone factoring the remailer keys.) |
From: Steve C. <st...@mi...> - 2013-08-12 08:51:40
|
On Sun, Aug 11, 2013 at 09:50:23PM +0100, li...@no... wrote: > > Where is a list of TODO items? The official repository is is on Debian. Here's a link to the currently revision of the TODO list. http://anonscm.debian.org/viewvc/pkg-mixmaster/trunk/Mix/TODO?revision=1005&view=markup I'd second the other responder though that doing work on Mixminion would probably be more productive. The author of Mixminion, Nick Mathewson, would probably be delighted if somebody took on development of it. |
From: adrelanos <adr...@ri...> - 2013-08-11 21:18:32
|
li...@no...: > > Where is a list of TODO items? > Why not rather work on a Type III remailer? Code: https://github.com/nmathewson/mixminion Todo: https://github.com/nmathewson/mixminion/blob/master/TODO I applaud if you step forward and become lead developer. It really just needs someone to start maintaining it. |
From: <li...@no...> - 2013-08-11 21:07:16
|
Where is a list of TODO items? |