| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 27 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 35:45:19 |
| Calls: | 631 |
| Calls today: | 2 |
| Files: | 1,187 |
| D/L today: |
22 files (29,767K bytes) |
| Messages: | 172,999 |
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
On 09.10.25 01:35, Linux-Mint-User wrote:
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
Has absolutely nothing to do with an iPhone or Android.
You are a Troll!
In article <10c75ui$oegi$3@solani.org>
=?UTF-8?Q?J=C3=B6rg_Lorenz?= <hugybear@gmx.net> wrote:
On 09.10.25 01:35, Linux-Mint-User wrote:
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
Has absolutely nothing to do with an iPhone or Android.
You are a Troll!
Whining noted.
In article <10c75ui$oegi$3@solani.org>
J%rg Lorenz <hugybear@gmx.net> wrote:
On 09.10.25 01:35, Linux-Mint-User wrote:
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
Has absolutely nothing to do with an iPhone or Android.
You are a Troll!
Whining noted.
Nomen Nescio <nobody@dizum.com> wrote:
In article <10c75ui$oegi$3@solani.org>
J||rg Lorenz <hugybear@gmx.net> wrote:
On 09.10.25 01:35, Linux-Mint-User wrote:
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
Has absolutely nothing to do with an iPhone or Android.
You are a Troll!
Whining noted.
The Claashole & GarbageX Troll Gang tries to discredit remailer usage.
But those idiots don't even know about MIME headers, which isn't the
only evident nonconformance of their custom brewed header section.
Nomen Nescio <nobody@dizum.com> wrote:
In article <10c75ui$oegi$3@solani.org>
J||rg Lorenz <hugybear@gmx.net> wrote:
Has absolutely nothing to do with an iPhone or Android.
You are a Troll!
Whining noted.
The Claashole & GarbageX Troll Gang tries to discredit remailer usage.
But those idiots don't even know about MIME headers, which isn't the
only evident nonconformance of their custom brewed header section.
Anonymous User once wrote:
Nomen Nescio <nobody@dizum.com> wrote:
In article <10c75ui$oegi$3@solani.org>
J||rg Lorenz <hugybear@gmx.net> wrote:
On 09.10.25 01:35, Linux-Mint-User wrote:
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
Has absolutely nothing to do with an iPhone or Android.
You are a Troll!
Whining noted.
The Claashole & GarbageX Troll Gang tries to discredit remailer usage.
Absolutely not true! https://github.com/Ch1ffr3punk/oc
But those idiots don't even know about MIME headers, which isn't the
only evident nonconformance of their custom brewed header section.
The only idiot is you, as we are aware of old-fashioned MIME headers.
The Claas troll wrote:
Anonymous User once wrote:
Nomen Nescio <nobody@dizum.com> wrote:
In article <10c75ui$oegi$3@solani.org>
J|a-|rg Lorenz <hugybear@gmx.net> wrote:
On 09.10.25 01:35, Linux-Mint-User wrote:
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
Has absolutely nothing to do with an iPhone or Android.
You are a Troll!
Whining noted.
The Claashole & GarbageX Troll Gang tries to discredit remailer usage.
Absolutely not true! https://github.com/Ch1ffr3punk/oc
Abandoned flawed type 1 design. We now have secure
Mixnmaster and YAMN, which are beyond the skills of
our trolls, who therefore try to discredit both.
The Onion Courier Mixnet, in case you have read and
*understood* the README, is by far much much more anonymous
and much much more secure than 30 years old Mixmaster SMTP
design and its 10 years old brother YAMN, which brings also
nothing new to the table!
*Try as typical OmniMix user* to understand the design philosophy
of the Onion Courier Mixnet and you will learn a lot!
Self-promoter Claas wrote:
The Onion Courier Mixnet, in case you have read and
*understood* the README, is by far much much more anonymous
and much much more secure than 30 years old Mixmaster SMTP
design and its 10 years old brother YAMN, which brings also
nothing new to the table!
So tell us some facts about the superiority of your system compared
with the Mixmaster / YAMN design, where for example we have
- a uniform packet design irrespective of message size
- chain lengths of 10+ remailers run by different entities
- message routing through multiple chains to increase reliability
- remailer mix pools of possibly hundreds of messages
- with variable latencies of up to several hours
- standard SMTP communication, optionally through Tor hidden services
- client-side cover traffic
- client access through Tor to hide remailer activities
- OmniMix SMTP/POP3/NNTP proxy server with SOCKS support
*Try as typical OmniMix user* to understand the design philosophy
of the Onion Courier Mixnet and you will learn a lot!
Now enlighten us item by item about the advantages of your system.
Self-promoter Claas wrote:
The Onion Courier Mixnet, in case you have read and
*understood* the README, is by far much much more anonymous
and much much more secure than 30 years old Mixmaster SMTP
design and its 10 years old brother YAMN, which brings also
nothing new to the table!
So tell us some facts about the superiority of your system compared
with the Mixmaster / YAMN design, where for example we have
- a uniform packet design irrespective of message size
- chain lengths of 10+ remailers run by different entities
- message routing through multiple chains to increase reliability
- remailer mix pools of possibly hundreds of messages
- with variable latencies of up to several hours
- standard SMTP communication, optionally through Tor hidden services
- client-side cover traffic
- client access through Tor to hide remailer activities
- OmniMix SMTP/POP3/NNTP proxy server with SOCKS support
*Try as typical OmniMix user* to understand the design philosophy
of the Onion Courier Mixnet and you will learn a lot!
Now enlighten us item by item about the advantages of your system.
Didn't we already have a Claas software check recently where that guy
failed miserably? IMO bothering with such an idiot is a waste of time.
Didn't we already have a Claas software check recently where that guy
failed miserably? IMO bothering with such an idiot is a waste of time.
Fritz Wuehler wrote:
Self-promoter Claas wrote:
The Onion Courier Mixnet, in case you have read and
*understood* the README, is by far much much more anonymous
and much much more secure than 30 years old Mixmaster SMTP
design and its 10 years old brother YAMN, which brings also
nothing new to the table!
So tell us some facts about the superiority of your system compared
with the Mixmaster / YAMN design, where for example we have
- a uniform packet design irrespective of message size
The Onion Courier Mixnet uses with it's client random adaptive padding
when sending messages, so that third parties do not know what is send, >compared to fixed padding payloads. Once the messages enters the pool
padding will be removed and then fixed size padding at each hop will
be applied.
- chain lengths of 10+ remailers run by different entities
Chain length is up to five hops, because this is IMHO enough for
Tor Hidden Services circuits, when run by different entities.
- message routing through multiple chains to increase reliability
The Onion Courier Mixnet, compared to the Mixmaster and YAMN Mixnet,
is totally decentralized and anonymous mix nodes can communicate with
public Tor Hidden Service mix nodes to form different chains.
- remailer mix pools of possibly hundreds of messages
The standard setting for an Onion Courier Mixnode is 1000 messages
for the pool.
- with variable latencies of up to several hours
The Onion Courier Mixnet has per hop standard latency between five to
20 minutes, so with five hops you get a maximum of 100 minutes. Messages
are choosen randomly when sent.
- standard SMTP communication, optionally through Tor hidden services
Onnion Courier uses modern http communication via Tor Hidden Services.
- client-side cover traffic
Same, but not automatically sent, like YAMN does when sending a message. >Users have to do this explicity, so that third parties do not know if
the user is sending a dummy message or a real one.
- client access through Tor to hide remailer activities
The Onion Courier Mixnet works exclusively as Tor Hidden Service
Mixnet and has Tor Hidden Service endpoint servers for clearnet >communication, which are not mix nodes but do not store or log
messages, but are sending messages directly to clearnet Usenet
or email addresses.
Users themselves have their own endpoint
(Tor Hidden Service) server to receive messages, therefore
avoiding classic nym server usage, hosted by third parties.
- OmniMix SMTP/POP3/NNTP proxy server with SOCKS support
*Try as typical OmniMix user* to understand the design philosophy
of the Onion Courier Mixnet and you will learn a lot!
Now enlighten us item by item about the advantages of your system.
Besides the points above. Messages entering the pool are encrypted with
24 hrs rotating keys, in RAM, which are memguard protected. So in case
third parties would look at the RAM pool (not a RAM disk) they would only
see encrypted blobs with equal size.
The Onion Courier Mixnet does also not log messages, like it is possible
with Mixmaster and YAMN MTA's and has no debugging log option like YAMN has.
The Onion Courier Mixnet CLI client works on smartphones too. One could
also run a mix node on his smartphone.
Pinger services are not needed because the client can ping mix nodes >directly.
Message size, the user can type, is
20 KB
and with the ocsend client, not
using mix nodes, one can send very large files to Onion Courier Mixnet home >servers.
Running an own Onion Courier Mixnet for family and friends is very
easy, compared to Mixmaster or YAMN, because you do not need to
register a domain, do not have to set-up postfix and you do not need
to monitor your mix node, because there is nothing to see when one is >running, compared to Mixmaster and YAMN possible MTA logs and open
pools at an exit remailer to see the final destination.
All in all the Onion Courier Mixnet, compared to the 30 years old
Mixmaster and 10 years old YAMN remailer Network, is a modern alternative
to classic remailing and even to the modern Nym Mixnet.
Fritz Wuehler wrote:
Self-promoter Claas wrote:
The Onion Courier Mixnet, in case you have read and
*understood* the README, is by far much much more anonymous
and much much more secure than 30 years old Mixmaster SMTP
design and its 10 years old brother YAMN, which brings also
nothing new to the table!
So tell us some facts about the superiority of your system compared
with the Mixmaster / YAMN design, where for example we have
- a uniform packet design irrespective of message size
- chain lengths of 10+ remailers run by different entities
- message routing through multiple chains to increase reliability
- remailer mix pools of possibly hundreds of messages
- with variable latencies of up to several hours
- standard SMTP communication, optionally through Tor hidden services
- client-side cover traffic
- client access through Tor to hide remailer activities
- OmniMix SMTP/POP3/NNTP proxy server with SOCKS support
*Try as typical OmniMix user* to understand the design philosophy
of the Onion Courier Mixnet and you will learn a lot!
Now enlighten us item by item about the advantages of your system.
Didn't we already have a Claas software check recently where that guy
failed miserably? IMO bothering with such an idiot is a waste of time.
Claas, there's nothing modern or innovative with what you present us
here. Type 2 remailing including nym servers stood the test of time,
whereas all of your strategies are old hat and dangerously flawed.
Claas wrote:
Besides the points above. Messages entering the pool are encrypted with
24 hrs rotating keys, in RAM, which are memguard protected. So in case third parties would look at the RAM pool (not a RAM disk) they would only see encrypted blobs with equal size.
You're naive. In a compromized VM they debug your processor registers
to get valid data.
People here in a.p.a-s can clearly see and distinguish between you guys and people
who do something for privacy and know something about it!
On Oct 8, 2025 at 7:35:27rC>PM EDT, "Linux-Mint-User" <"LM..."@Mint.Users.com>
wrote:
The Complete PGP Encryption Tutorial - Gpg4win & GnuPG
Easy tutorial, windows first, linux at 13:37...
https://www.youtube.com/watch?v=CEADq-B8KtI
Why are you crossposting this to misc.phone.mobile.iphone? No one with an iPhone gives a damn about Linux. Most won't even know what it is.
On 2025-10-10 21:37, Onion Courier wrote:
People here in a.p.a-s can clearly see and distinguish between you guys and people
who do something for privacy and know something about it!
People here in c.m.a are simply tired of your offtopic.
Fritz Wuehler wrote:
Claas wrote:
Besides the points above. Messages entering the pool are encrypted with
24 hrs rotating keys, in RAM, which are memguard protected. So in case
third parties would look at the RAM pool (not a RAM disk) they would only >> > see encrypted blobs with equal size.
You're naive. In a compromized VM they debug your processor registers
to get valid data.
Give us an example of how it compares to YAMN or Mixmaster, with their
open pools, and my implementation, so I and others can learn from it.
(and do not forget People can run their Onion Courier Mixnets from home!)
IIRC correcly, when I ran myself Mixmaster and YAMN remailers, I could
look into the pool and see messages and there destinations, along their >padded encrypted payload. I had never ran logs, but I know from postix
how they work.
So, do a comparison and let us know the results. If my implementation
is flawed I will correct it and ask for better memguard advise for the >rotating keys at the right places.
Fritz Wuehler wrote:
Claas, there's nothing modern or innovative with what you present us
here. Type 2 remailing including nym servers stood the test of time,
whereas all of your strategies are old hat and dangerously flawed.
Why do you call it TypeI remailing, when you know it is not?
You can put the Onion Courier Mixnet as much as you want in a bad light, >which might be even your duty, because you hate that it is not controlable
by third parties, like you can do with the Mixmaster and YAMN Network, to >even get your hands on remops.
You hate the idea that people can easily
run their own anonymous Mixnets worldwide for family and friends, decentralized,
and at home, while interacting with public mix node too, which you can't and never
will do with Mixmaster or YAMN, period!
OmniMix is also pretty much outdated due to
it's GUI design, which even would not be useable on smartphones, should Danner be
capable to port it to Android or iOS.
His OrMail is just a copy of my previous
Onion Courier Network and Mini Mailer smtpdump+ Network.
Old Mixnets like yours fail miserably, when comparing it to the Onion Courier >Mixnet and *you know that*! You only can hide with Mixmaster,YAMN, *thanks to Tor!*
*Remember that!*
People here in a.p.a-s can clearly see and distinguish between you guys and people
who do something for privacy and know something about it!
EOD
Fritz Wuehler wrote:
Claas wrote:
Besides the points above. Messages entering the pool are encrypted with
24 hrs rotating keys, in RAM, which are memguard protected. So in case
third parties would look at the RAM pool (not a RAM disk) they would only >> > see encrypted blobs with equal size.
You're naive. In a compromized VM they debug your processor registers
to get valid data.
Give us an example of how it compares to YAMN or Mixmaster, with their
open pools, and my implementation, so I and others can learn from it.
(and do not forget People can run their Onion Courier Mixnets from home!)
IIRC correcly, when I ran myself Mixmaster and YAMN remailers, I could
look into the pool and see messages and there destinations, along their >padded encrypted payload. I had never ran logs, but I know from postix
how they work.
So, do a comparison and let us know the results. If my implementation
is flawed I will correct it and ask for better memguard advise for the >rotating keys at the right places.
You're mad! He did a comparison including a score for each of the items.
The most severe problems seem to be
| >> So tell us some facts about the superiority of your system compared
| >> with the Mixmaster / YAMN design, where for example we have
| >>
| >> - a uniform packet design irrespective of message size
| >
| >The Onion Courier Mixnet uses with it's client random adaptive padding
| >when sending messages, so that third parties do not know what is send,
| >compared to fixed padding payloads. Once the messages enters the pool
| >padding will be removed and then fixed size padding at each hop will
| >be applied.
|
| Worse - That's a devastating flaw of your not so modern Type 1 system,
| as padding only increases size and a larger message is doomed to stick
| out like a sore thumb, whereas with Type 2 remailers all packets are of
| equal size of 4 kB (Mixmaster) or 20 kB (YAMN) with larger messages
| being split and reassembled at the exit remailer. That's the main
| reason why Type 1 remailing is obsolete and was abandoned years ago in
| favour of Type 2 Mixmaster / YAMN!
and
| >> - message routing through multiple chains to increase reliability
| >
| >The Onion Courier Mixnet, compared to the Mixmaster and YAMN Mixnet,
| >is totally decentralized and anonymous mix nodes can communicate with
| >public Tor Hidden Service mix nodes to form different chains.
|
| Worse - Correct me if I'm wrong, but AFAICS each message is sent through
| just one single chain of nodes, which means it gets lost if one of these
| nodes is down.
To me those are knockout criteria.
So a simple question: Is he right?
Fritz Wuehler wrote:
Claas, there's nothing modern or innovative with what you present us
here. Type 2 remailing including nym servers stood the test of time,
whereas all of your strategies are old hat and dangerously flawed.
Why do you call it TypeI remailing, when you know it is not?
You can put the Onion Courier Mixnet as much as you want in a bad light, >which might be even your duty, because you hate that it is not controlable
by third parties, like you can do with the Mixmaster and YAMN Network, to >even get your hands on remops. You hate the idea that people can easily
run their own anonymous Mixnets worldwide for family and friends, decentralized,
and at home, while interacting with public mix node too, which you can't and never
will do with Mixmaster or YAMN, period! OmniMix is also pretty much outdated due to
it's GUI design, which even would not be useable on smartphones, should Danner be
capable to port it to Android or iOS. His OrMail is just a copy of my previous >Onion Courier Network and Mini Mailer smtpdump+ Network.
Old Mixnets like yours fail miserably, when comparing it to the Onion Courier >Mixnet and *you know that*! You only can hide with Mixmaster,YAMN, *thanks to Tor!*
*Remember that!*
People here in a.p.a-s can clearly see and distinguish between you guys and people
who do something for privacy and know something about it!
EOD
Yamn Remailer wrote:
You're mad! He did a comparison including a score for each of the items.
The most severe problems seem to be
| >> So tell us some facts about the superiority of your system compared
| >> with the Mixmaster / YAMN design, where for example we have
| >>
| >> - a uniform packet design irrespective of message size
| >
| >The Onion Courier Mixnet uses with it's client random adaptive padding
| >when sending messages, so that third parties do not know what is send,
| >compared to fixed padding payloads. Once the messages enters the pool
| >padding will be removed and then fixed size padding at each hop will
| >be applied.
|
| Worse - That's a devastating flaw of your not so modern Type 1 system,
| as padding only increases size and a larger message is doomed to stick
| out like a sore thumb, whereas with Type 2 remailers all packets are of
| equal size of 4 kB (Mixmaster) or 20 kB (YAMN) with larger messages
| being split and reassembled at the exit remailer. That's the main
| reason why Type 1 remailing is obsolete and was abandoned years ago in
| favour of Type 2 Mixmaster / YAMN!
and
| >> - message routing through multiple chains to increase reliability
| >
| >The Onion Courier Mixnet, compared to the Mixmaster and YAMN Mixnet,
| >is totally decentralized and anonymous mix nodes can communicate with
| >public Tor Hidden Service mix nodes to form different chains.
|
| Worse - Correct me if I'm wrong, but AFAICS each message is sent through >> | just one single chain of nodes, which means it gets lost if one of these >> | nodes is down.
To me those are knockout criteria.
So a simple question: Is he right?
We should ask ourselves the following questions for a) and b).
a) What can ISPs see when examining tor cells, each 514 bytes in size? Can they
count that you always send equal in size remailer packets when using YAMN and know then that you use a remailer service? I would say yes. With adaptive padding they have a much harder time to guess, no?
b) Don't you loose remailer packets, if you use copies=n with the same chain when one node is down or when selecting random yamn chains and a node is down?
The Claas sock puppet Bob <bob@radio-eriwan.ru> aka fascist Juri wrote:
No, no, no. You try to fool us once again. The key question above, which you're blinking, is clear and fair. And your avoidance speaks volumes.
IOW he's absolutely right and your oh so modern innovative system is
nothing more than utter rubbish. Claas, you're simply an ugly POS!
The Onion Courier salesman rants:
People here in a.p.a-s can clearly see and distinguish between you guys and people
who do something for privacy and know something about it!
EOD
Port OmniMix to Android or iOS smartphones, which are the most insecure >spying devices imaginable? Really? And OTOH you urge us to migrate to
Linux as Windows is so risky? You've got bats in your belfry, dimbulb.
Yamn Remailer wrote:
You're mad! He did a comparison including a score for each of the items.
The most severe problems seem to be
| >> So tell us some facts about the superiority of your system compared
| >> with the Mixmaster / YAMN design, where for example we have
| >>
| >> - a uniform packet design irrespective of message size
| >
| >The Onion Courier Mixnet uses with it's client random adaptive padding
| >when sending messages, so that third parties do not know what is send,
| >compared to fixed padding payloads. Once the messages enters the pool
| >padding will be removed and then fixed size padding at each hop will
| >be applied.
|
| Worse - That's a devastating flaw of your not so modern Type 1 system,
| as padding only increases size and a larger message is doomed to stick
| out like a sore thumb, whereas with Type 2 remailers all packets are of
| equal size of 4 kB (Mixmaster) or 20 kB (YAMN) with larger messages
| being split and reassembled at the exit remailer. That's the main
| reason why Type 1 remailing is obsolete and was abandoned years ago in
| favour of Type 2 Mixmaster / YAMN!
and
| >> - message routing through multiple chains to increase reliability
| >
| >The Onion Courier Mixnet, compared to the Mixmaster and YAMN Mixnet,
| >is totally decentralized and anonymous mix nodes can communicate with
| >public Tor Hidden Service mix nodes to form different chains.
|
| Worse - Correct me if I'm wrong, but AFAICS each message is sent through >> | just one single chain of nodes, which means it gets lost if one of these >> | nodes is down.
To me those are knockout criteria.
So a simple question: Is he right?
We should ask ourselves the following questions for a) and b).
a) What can ISPs see when examining tor cells, each 514 bytes in size? Can they
count that you always send equal in size remailer packets when using YAMN and know then that you use a remailer service? I would say yes. With adaptive padding they have a much harder time to guess, no?
b) Don't you loose remailer packets, if you use copies=n with the same chain when one node is down or when selecting random yamn chains and a node is down?
A rather stupid Anonymous User, using OmniMix, wrote:
The Claas sock puppet Bob <bob@radio-eriwan.ru> aka fascist Juri wrote:
No, no, no. You try to fool us once again. The key question above, which
you're blinking, is clear and fair. And your avoidance speaks volumes.
Answer the 514 bytes tor cells question, moron!
IOW he's absolutely right and your oh so modern innovative system is
nothing more than utter rubbish. Claas, you're simply an ugly POS!
says an *OmniMix Idiot*...
Bob <bob@radio-eriwan.ru> wrote:
A rather stupid Anonymous User, using OmniMix, wrote:
The Claas sock puppet Bob <bob@radio-eriwan.ru> aka fascist Juri wrote:
No, no, no. You try to fool us once again. The key question above, which you're blinking, is clear and fair. And your avoidance speaks volumes.
Answer the 514 bytes tor cells question, moron!
IOW he's absolutely right and your oh so modern innovative system is nothing more than utter rubbish. Claas, you're simply an ugly POS!
says an *OmniMix Idiot*...
Once again a confirmation that he tried to sell us a flawed type 1
remailer system. And focussing on OM's more or less irrelevant Tor
usage for handing over packets to the remailer network, which then
does the essential work, is remarkable. As remarkable as the Claas
idiot's appearance here as "Bob" because he's ashamed of himself.
The Claas sock puppet Bob <bob@radio-eriwan.ru> aka fascist Juri wrote:
Yamn Remailer wrote:
You're mad! He did a comparison including a score for each of the items. >>>
The most severe problems seem to be
| >> So tell us some facts about the superiority of your system compared >>> | >> with the Mixmaster / YAMN design, where for example we have
| >>
| >> - a uniform packet design irrespective of message size
| >
| >The Onion Courier Mixnet uses with it's client random adaptive padding >>> | >when sending messages, so that third parties do not know what is send, >>> | >compared to fixed padding payloads. Once the messages enters the pool >>> | >padding will be removed and then fixed size padding at each hop will
| >be applied.
|
| Worse - That's a devastating flaw of your not so modern Type 1 system, >>> | as padding only increases size and a larger message is doomed to stick >>> | out like a sore thumb, whereas with Type 2 remailers all packets are of >>> | equal size of 4 kB (Mixmaster) or 20 kB (YAMN) with larger messages
| being split and reassembled at the exit remailer. That's the main
| reason why Type 1 remailing is obsolete and was abandoned years ago in >>> | favour of Type 2 Mixmaster / YAMN!
and
| >> - message routing through multiple chains to increase reliability
| >
| >The Onion Courier Mixnet, compared to the Mixmaster and YAMN Mixnet,
| >is totally decentralized and anonymous mix nodes can communicate with >>> | >public Tor Hidden Service mix nodes to form different chains.
|
| Worse - Correct me if I'm wrong, but AFAICS each message is sent through >>> | just one single chain of nodes, which means it gets lost if one of these >>> | nodes is down.
To me those are knockout criteria.
So a simple question: Is he right?
We should ask ourselves the following questions for a) and b).
No, no, no. You try to fool us once again. The key question above, which >you're blinking, is clear and fair. And your avoidance speaks volumes.
a) What can ISPs see when examining tor cells, each 514 bytes in size? Can they
count that you always send equal in size remailer packets when using YAMN and know then that you use a remailer service? I would say yes. With adaptive padding they have a much harder time to guess, no?
b) Don't you loose remailer packets, if you use copies=n with the same chain when one node is down or when selecting random yamn chains and a node is down?
IOW he's absolutely right and your oh so modern innovative system is
nothing more than utter rubbish. Claas, you're simply an ugly POS!
Yamn Remailer wrote:
You're mad! He did a comparison including a score for each of the items.
The most severe problems seem to be
| >> So tell us some facts about the superiority of your system compared
| >> with the Mixmaster / YAMN design, where for example we have
| >>
| >> - a uniform packet design irrespective of message size
| >
| >The Onion Courier Mixnet uses with it's client random adaptive padding
| >when sending messages, so that third parties do not know what is send,
| >compared to fixed padding payloads. Once the messages enters the pool
| >padding will be removed and then fixed size padding at each hop will
| >be applied.
|
| Worse - That's a devastating flaw of your not so modern Type 1 system,
| as padding only increases size and a larger message is doomed to stick
| out like a sore thumb, whereas with Type 2 remailers all packets are of
| equal size of 4 kB (Mixmaster) or 20 kB (YAMN) with larger messages
| being split and reassembled at the exit remailer. That's the main
| reason why Type 1 remailing is obsolete and was abandoned years ago in
| favour of Type 2 Mixmaster / YAMN!
and
| >> - message routing through multiple chains to increase reliability
| >
| >The Onion Courier Mixnet, compared to the Mixmaster and YAMN Mixnet,
| >is totally decentralized and anonymous mix nodes can communicate with
| >public Tor Hidden Service mix nodes to form different chains.
|
| Worse - Correct me if I'm wrong, but AFAICS each message is sent through >> | just one single chain of nodes, which means it gets lost if one of these >> | nodes is down.
To me those are knockout criteria.
So a simple question: Is he right?
We should ask ourselves the following questions for a) and b).
a) What can ISPs see when examining tor cells, each 514 bytes in size?
Can they
count that you always send equal in size remailer packets when using YAMN and know then that you use a remailer service?
I would say yes.
With adaptive padding they have a much harder time to guess, no?
b) Don't you loose remailer packets, if you use copies=n with the same chain when one node is down or when selecting random yamn chains and a node is down?
The Claas sock puppet Bob <bob@radio-eriwan.ru> aka fascist Juri wrote:
Yamn Remailer wrote:
You're mad! He did a comparison including a score for each of the items. >>>
The most severe problems seem to be
| >> So tell us some facts about the superiority of your system compared >>> | >> with the Mixmaster / YAMN design, where for example we have
| >>
| >> - a uniform packet design irrespective of message size
| >
| >The Onion Courier Mixnet uses with it's client random adaptive padding >>> | >when sending messages, so that third parties do not know what is send, >>> | >compared to fixed padding payloads. Once the messages enters the pool >>> | >padding will be removed and then fixed size padding at each hop will
| >be applied.
|
| Worse - That's a devastating flaw of your not so modern Type 1 system, >>> | as padding only increases size and a larger message is doomed to stick >>> | out like a sore thumb, whereas with Type 2 remailers all packets are of >>> | equal size of 4 kB (Mixmaster) or 20 kB (YAMN) with larger messages
| being split and reassembled at the exit remailer. That's the main
| reason why Type 1 remailing is obsolete and was abandoned years ago in >>> | favour of Type 2 Mixmaster / YAMN!
and
| >> - message routing through multiple chains to increase reliability
| >
| >The Onion Courier Mixnet, compared to the Mixmaster and YAMN Mixnet,
| >is totally decentralized and anonymous mix nodes can communicate with >>> | >public Tor Hidden Service mix nodes to form different chains.
|
| Worse - Correct me if I'm wrong, but AFAICS each message is sent through >>> | just one single chain of nodes, which means it gets lost if one of these >>> | nodes is down.
To me those are knockout criteria.
So a simple question: Is he right?
We should ask ourselves the following questions for a) and b).
No, no, no. You try to fool us once again. The key question above, which >you're blinking, is clear and fair. And your avoidance speaks volumes.
a) What can ISPs see when examining tor cells, each 514 bytes in size? Can they
count that you always send equal in size remailer packets when using YAMN and know then that you use a remailer service? I would say yes. With adaptive padding they have a much harder time to guess, no?
b) Don't you loose remailer packets, if you use copies=n with the same chain when one node is down or when selecting random yamn chains and a node is down?
IOW he's absolutely right and your oh so modern innovative system is
nothing more than utter rubbish. Claas, you're simply an ugly POS!
Even the story Claas told us about once having been in contact
with our cypherpunk heroes now looks like just another lie, as
he pisses at Lance Cottrell, Len Sassaman, Peter Palfrader and
Steven Crook, the inventors and maintainers of secure Type II
remailing applications. He really is a miserable creature.
When YAMN is not properly configured it bypasses
Tor and sends via mixmin, what I discussed here long ago with inwtx.
So you guys better shut-up or fuck off!
In article <20251011175032.mbJuNryfq57T@sewer.dizum.com> Nomen Nescio wrote:
When YAMN is not properly configured it bypasses
Tor and sends via mixmin, what I discussed here long ago with inwtx.
Look at line 90 in mail.go :(
<https://github.com/search?q=repo%3Acrooks%2Fyamn%20onion&type=code>
Solution: yamn-proxy. :)
https://github.com/Ch1ffr3punk/yamn-proxy
So you guys better shut-up or fuck off!
+1