m2usenet Gateway v2.0 :
http://itcxzfm2h36hfj6j7qxksyfm4ipp3co4rkl62sgge7hp6u77lbretiyd.onion:8880
https://m2usenet.virebent.art
Gabx
[padding:6e52c841cd00d6a2c9553795f693096bdcff977d8b20a4db5fa4796f6486892056ee09fc71ea54067a13d4af2ee5fb89e41b80f2bd6f6956e472cdf51b30cb21eb2436abdb93783598244dbc12238e9fdf07562a9009fd4a9601f2af6a236291c1d88660def038c455d9bf722d5158da52319a5c302af7f8e922fd31090b5cbe0ec7c30345d30baa8d6d08690c700cc0614abdeebc8b269c355cec0764408d57da6babf0d89204aebf0bff65857f0dc4ab3ccbe0c8559ec860fc617f9235763d949be76a0a3f4bfdc00d0c9fb7e95815e4dc768b27ef6edaed7842634c6eb07a3f22cd05d3f6105c4596110fbe4ab885e4bccde22d3830bea9a048ae5a516626]
https://m2usenet.virebent.art
What I don't understand, why the POW cannot be automatically
done by the server, without user input and why a digital sig
is used, nobody can verify because a server or third parties
would never fiddle around with the usual Usenet blah blah...
Gabx:
What I don't understand, why the POW cannot be automatically
done by the server, without user input and why a digital sig
is used, nobody can verify because a server or third parties
would never fiddle around with the usual Usenet blah blah...
After hours of development, testing, putting online, everything totally live, m2usenet 2.0 can be considered available for testing. there shouldn't be any problems thou.
I have got good news anyway, check it:
https://m2usenet.virebent.art/
http://itcxzfm2h36hfj6j7qxksyfm4ipp3co4rkl62sgge7hp6u77lbretiyd.onion:8880/
Have fun !!!
Gabx
After hours of development, testing, putting online, everything totally live, m2usenet 2.0 can be considered available for testing. there shouldn't be any problems thou.
I have got good news anyway, check it:
https://m2usenet.virebent.art/
http://itcxzfm2h36hfj6j7qxksyfm4ipp3co4rkl62sgge7hp6u77lbretiyd.onion:8880/
Have fun !!!
Gabx
I keep getting a please enter a valid email address.
In article <1760746012.119f7b7091c05686d451aa2078d17428@m2usenet.local>
Gabx <victor@virbent.tcpreset> wrote:
After hours of development, testing, putting online, everything totally live, m2usenet 2.0 can be considered available for testing. there shouldn't be any problems thou.
I have got good news anyway, check it:
https://m2usenet.virebent.art/
http://itcxzfm2h36hfj6j7qxksyfm4ipp3co4rkl62sgge7hp6u77lbretiyd.onion:8880/ >>
Have fun !!!
Gabx
I keep getting a please enter a valid email address.
Looks like poisoned snake oil offered by GarbageX!
Yamn2 Remailer wrote:
Looks like poisoned snake oil offered by GarbageX!
This is the classic non-technical critique from people who blindly trust >closed-source software with ambiguous licenses while lecturing others
about privacy.
Let me address the technical illiteracy in your comment:
m2usenet is fully open source: https://github.com/gabrix73/m2usenet-go
You can:
- Audit every line of JavaScript before running it
- Host your own instance
- Verify the client-side crypto with browser dev tools
- Review the Ed25519 and Hashcash implementations
Compare this to your beloved Omnimix and similar systems with:
- Closed source binaries you run blindly
- Ambiguous licensing terms
- *"Trust us" security model*
m2usenet is transparent, auditable, and follows
cryptographic best practices.
If you have actual technical criticisms of the implementation, I'm >listening.
But "why client-side crypto" from someone who trusts closed binaries? Please.
The code speaks for itself. Unlike some systems.
Ed25519 signatures provide message integrity even with ephemeral keys - >basic cryptographic hygiene that apparently escapes you.
Gabx
So you recommend spammers for fairness reasons to select more bits? No kidding?
Man! You're really a droll fellow.
As you also post to sci.crypt we have here experts in this field.
First of all, OmniMix isn't closed source software even if you repeat
that lie again and again. Why do you do that as you know better? Fact
is that with OmniMix you even get the complete IDE, which with a few
mouse clicks builds the executable program on your computer ready to be
run in a debugger step by step and compared with the file from the installation package byte by byte. You're in control of everything!
Now to your web interface. There we have the exact oposite. You
present us source code, but whether that's what processes our data is
beyond our control. Even if we once or twice download the published
code the next time for whatever reason it may be different and
compromize our identity. A system for gamblers.
Furthermore, the anonymity of our plain text messages is secured by an extremely weak real-time Tor connection of usually no more than 3 nodes
while with OmniMix you're allowed to route your data through much longer
Tor circuits and those data aren't plain text but multilayer-encrypted remailer packets.
And then there still is the unanswered question of a signature based on
a single-use throwaway key, where the user only gets knowledge of the
public key but not the secret key or the passphrase, both only known to
you as the service provider. That's weird. It doesn't verify anything.
It just proves that the user is stupid enough to deal with your insecure
web interface.
Equally weird is your statement about Hashcash bits in MID <1760739178.dcc2021df3109aecc5b428f2d8ff300f@m2usenet.local>:
| 16bit option is fast.
| But not recommended, thou !
So you recommend spammers for fairness reasons to select more bits? No kidding?
Man! You're really a droll fellow.
Yamn2 Remailer wrote:
So you recommend spammers for fairness reasons to select more bits? No
kidding?
Man! You're really a droll fellow.
You think it's week we can talk about,
but this is not the way to say it.
Yes omnimix is the best.
Lunga vita
Gabx
So this response isn't for the trolls or the blind fanboys.
It's for anyone who genuinely wants to understand the technical details.
Gabx <victor@tcpreset.virebent> wrote:
Yamn2 Remailer wrote:
Looks like poisoned snake oil offered by GarbageX!
This is the classic non-technical critique from people who blindly trust >>>closed-source software with ambiguous licenses while lecturing others >>>about privacy.
Yamn2 Remailer wrote:
As you also post to sci.crypt we have here experts in this field.
And you are not part of them.
First of all, OmniMix isn't closed source software even if you repeat
that lie again and again. Why do you do that as you know better? Fact
is that with OmniMix you even get the complete IDE, which with a few
mouse clicks builds the executable program on your computer ready to be
run in a debugger step by step and compared with the file from the
installation package byte by byte. You're in control of everything!
"Providing an IDE to compile is not equivalent to 'open source' in the
OSI definition.
Open source requires:
- Public source code repository
- OSI-approved license (GPL, MIT, BSD, etc.)
- Right to modify and redistribute
If OmniMix meets these criteria, I stand corrected.
A link to the public repository would clarify this."
Now to your web interface. There we have the exact oposite. You
present us source code, but whether that's what processes our data is
beyond our control. Even if we once or twice download the published
code the next time for whatever reason it may be different and
compromize our identity. A system for gamblers.
For maximum security: Self-host your own instance. That's why it's
open source.
Furthermore, the anonymity of our plain text messages is secured by an
extremely weak real-time Tor connection of usually no more than 3 nodes
while with OmniMix you're allowed to route your data through much longer
Tor circuits and those data aren't plain text but multilayer-encrypted
remailer packets.
Calling Tor "extremely weak" with "no more than 3 nodes" shows a
fundamental misunderstanding of the architecture, for both tor and m2usenet.
m2usenet routes through THREE Tor hidden services:
1. Pluto2 SMTP relay (.onion)
2. mail2news gateway (.onion)
3. NNTP server (.onion)
Each hidden service connection uses 3 hops. Total: 9+ hops minimum.
Calling this "weak" is not a technical argument, it's dismissive rhetoric.
And then there still is the unanswered question of a signature based on
a single-use throwaway key, where the user only gets knowledge of the
public key but not the secret key or the passphrase, both only known to
you as the service provider. That's weird. It doesn't verify anything.
It just proves that the user is stupid enough to deal with your insecure
web interface.
- keyPair generated client-side
- keyPair.secretKey stays IN BROWSER MEMORY (never transmitted)
- Only publicKey + signature sent to server
- Server CANNOT access secretKey
Equally weird is your statement about Hashcash bits in MID
<1760739178.dcc2021df3109aecc5b428f2d8ff300f@m2usenet.local>:
| 16bit option is fast.
| But not recommended, thou !
So you recommend spammers for fairness reasons to select more bits? No
kidding?
The difficulty levels serve different purposes:
- 16 bits: Prevents message flooding
- 20 bits (default): Balanced protection (~5-10 seconds per post)
- 24 bits: Strong protection (~30-60 seconds per post)
- 28 bits: Very strong (~several minutes per post)
Real spammers use botnets with GPU/ASIC mining, not browser interfaces.
A web UI with mandatory proof-of-work is specifically designed to
PREVENT automated spam tools.
Man! You're really a droll fellow.
Gabx
So this response isn't for the trolls or the blind fanboys.
It's for anyone who genuinely wants to understand the technical details.
Yamn2 Remailer wrote:
As you also post to sci.crypt we have here experts in this field.
And you are not part of them.
You're not droll. You're a troll, a liar, a forger, simply an idiot!
Gabx <info@tcpreset.invalid> wrote:
So this response isn't for the trolls or the blind fanboys.
It's for anyone who genuinely wants to understand the technical details.
Yamn2 Remailer wrote:
As you also post to sci.crypt we have here experts in this field.
And you are not part of them.
I'm not part of them but I wonder why the experts continued to enhance Mixmaster and Yamn remailing after the Tor network started in 2006? Stupidity? Or ample spare time? I doubt it.
Yamn2 Remailer wrote:
As you also post to sci.crypt we have here experts in this field.
And you are not part of them.
Which you're a judge of? OMG!
"Providing an IDE to compile is not equivalent to 'open source' in the
OSI definition.
Open source requires:
- Public source code repository
- OSI-approved license (GPL, MIT, BSD, etc.)
- Right to modify and redistribute
For maximum security: Self-host your own instance. That's why it's
open source.
So we have to run our own webserver to get some kind of security? OMG!
Furthermore, the anonymity of our plain text messages is secured by an
extremely weak real-time Tor connection of usually no more than 3 nodes
while with OmniMix you're allowed to route your data through much longer >>> Tor circuits and those data aren't plain text but multilayer-encrypted
remailer packets.
Calling Tor "extremely weak" with "no more than 3 nodes" shows a
fundamental misunderstanding of the architecture, for both tor and m2usenet. >>
m2usenet routes through THREE Tor hidden services:
1. Pluto2 SMTP relay (.onion)
2. mail2news gateway (.onion)
3. NNTP server (.onion)
Each hidden service connection uses 3 hops. Total: 9+ hops minimum.
And at every stage the clear text message is available! OMG!
Yamn2 Remailer wrote:
So you recommend spammers for fairness reasons to select more bits? No
kidding?
Man! You're really a droll fellow.
You think it's week we can talk about,
but this is not the way to say it.
Yes omnimix is the best.
Lunga vita
Gabx
Anonymous wrote:
You're not droll. You're a troll, a liar, a forger, simply an idiot!Lol
If you use omnimix and you're happy to do so, use it, I have nothing
against it, then you're so technical that you surely know what you're
doing, keep using omnimix.
Once again, there is nothing technical to answer, other than a stupid
and childish, "omnimix is ??better, you suck".
Just troll considerations and that's it.
I've already given you too much confidence.
Get a life baby !!!
Yamn Remailer wrote:
Gabx <info@tcpreset.invalid> wrote:
So this response isn't for the trolls or the blind fanboys.
It's for anyone who genuinely wants to understand the technical details. >> >
Yamn2 Remailer wrote:
As you also post to sci.crypt we have here experts in this field.
And you are not part of them.
I'm not part of them but I wonder why the experts continued to enhance
Mixmaster and Yamn remailing after the Tor network started in 2006?
Stupidity? Or ample spare time? I doubt it.
Please explain. What was introcuded IIRC was that Elvis added 4k key
support to Mixmaster and Zax added modern Crypto and anti-tagging to
YAMN.
So what more anonymity you gain with them when already using Tor?
With YAMN's security flaws you can be easily de-anonymized.
Stefan Claas <bounce.me@oc2mx.net> wrote:
With YAMN's security flaws you can be easily de-anonymized.
Which security flaws? You don't think of Internet I/O which anyhow has
to be handled by specialized communication software like OmniMix?
Anonymous wrote:
Yamn2 Remailer wrote:
As you also post to sci.crypt we have here experts in this field.
And you are not part of them.
Which you're a judge of? OMG!
You acted so tough and now you're crying?
"Providing an IDE to compile is not equivalent to 'open source' in the
OSI definition.
Open source requires:
- Public source code repository
- OSI-approved license (GPL, MIT, BSD, etc.)
- Right to modify and redistribute
It's not opensource !
For maximum security: Self-host your own instance. That's why it's
open source.
So we have to run our own webserver to get some kind of security? OMG!
Omnimix does run its own internal servers.
Ok maybe you ignore it, this is taken from the official site, but
omnimix has servers, check this out: >https://www.danner-net.de/omom/tutorinstall.htm
:O that's amazing isn't it?
rCo*Tor* Used for an additional anonymization of the connections from your >computer to the Internet. It hides which servers you contact and which
of their services (mail delivery and retrieval, Usenet access to
download nym messages etc.) you use. You're allowed to integrate a >preexisting Tor installation as well, but keep in mind, that all
connections that use the same Tor routing might be assigned to each
other by an adversary! On the other hand there's no restriction in
running several Tor systems simultaneously. The Tor client integrated in >OmniMix offers the advantage of having the whole anonymizer software >removable in one place without leaving any traces elsewhere.
rCo*Hamster* News server used to download the alt.anonymous.messages >newsgroup and cache it locally in order to extract nym reply messages.
You're against servers and no one warned you before installing?
You see? I'm right!
Furthermore, the anonymity of our plain text messages is secured by an >>>> extremely weak real-time Tor connection of usually no more than 3 nodes >>>> while with OmniMix you're allowed to route your data through much longer >>>> Tor circuits and those data aren't plain text but multilayer-encrypted >>>> remailer packets.
3 hopes is considered standard enough !
**Behavioral Fingerprinting**
"Using non-standard circuit lengths makes you part of a tiny, easily >identifiable subset. If only 0.1% of Tor users run modified clients, you >become statistically unique.
**Failure Cascade**
Each additional hop increases circuit failure rates. A 7-hop circuit can >experience up to 8% failures, making connections unreliable, compared to
~1% for a standard circuit.
**Timing Analysis Vulnerability**
Extended circuits create distinctive timing patterns during their >construction that can be fingerprinted, potentially revealing your
modified client to network monitors.
**Compromised Node Paradox**
More hops mean a higher probability of hitting a compromised or
malicious node within the circuit, increasing your overall risk exposure.
Important Security Consideration: Better performance for specific
protocols like email doesn't magically fix the fundamental
fingerprinting vulnerabilities. You are still marking yourself as a
unique user.
This is not just me saying this but this link also talks about it.
https://www.sciencedirect.com/topics/computer-science/compromised-node
Calling Tor "extremely weak" with "no more than 3 nodes" shows a
fundamental misunderstanding of the architecture, for both tor and m2usenet.
m2usenet routes through THREE Tor hidden services:
1. Pluto2 SMTP relay (.onion)
2. mail2news gateway (.onion)
3. NNTP server (.onion)
Each hidden service connection uses 3 hops. Total: 9+ hops minimum.
And at every stage the clear text message is available! OMG!
???????
I don't understand what you're talking about.
so I cut the rest.
It's not based on any real facts, anyway.
it's just nonsense.
Gabx
Anonymous User wrote:
Stefan Claas <bounce.me@oc2mx.net> wrote:
With YAMN's security flaws you can be easily de-anonymized.
Which security flaws? You don't think of Internet I/O which anyhow has
to be handled by specialized communication software like OmniMix?
First of all, Zax should IMHO seperate the client form the remailer
code, so that users can focus on one program.
I do not use OmniMix, so I can't speak for it.
YAMN has the following security flaws:
a) It does not want onion addresses to been used in the MX code
and Zax should really tell us why!
b) Users new to remailing with YAMN, see only at his repository
minimal configuration files, which are of not much help, IMHO.
But the problem is, if you do not look close at his source code
IIRC in config.go, the YAMN client, when set-up not properly,
with socat, can and does bypass your Tor settings in socat and
sends via clearnet to mixmin, filling up his log files and then
crashing his server. Remops know that when analyzing MTA logs
that they include the IP address from the originating client, if
Tor is bypassed, and to whom the email goes. *That is definetily
an absolute no-go* and Zax should explain to us why he coded it
that way for client usage, if users are unaware of this! I am
talking of the internal MXRelay = true setting, which should
be by default set to false in his source code. Mixmaster IIRC
does not do this.
c) Zax should better use Go's proxy package for a seperate
YAMN client, so that stats and pub keys can be fetched via
Tor and also remailing is done via Tor.
He should really tell us all, what has driven him to not
like onions, which can be seen IIRC in mail.go.
YAMN in it's current form tells me unfortunately that you
must rely on the old a.p.a-s saying "trust nobody" :-(
Hence the reasone I released yamn-proxy. :-)
https://github.com/Ch1ffr3punk/yamn-proxy
Regards
Stefan
Furthermore, the anonymity of our plain text messages is secured by an >>>>> extremely weak real-time Tor connection of usually no more than 3 nodes >>>>> while with OmniMix you're allowed to route your data through much longer >>>>> Tor circuits and those data aren't plain text but multilayer-encrypted >>>>> remailer packets.
3 hopes is considered standard enough !
In this group there once was a risk calculation which didn't look very promising with only 3 hops. I wouldn't bet on it.
**Behavioral Fingerprinting**
"Using non-standard circuit lengths makes you part of a tiny, easily
identifiable subset. If only 0.1% of Tor users run modified clients, you
become statistically unique.
No proof.
**Failure Cascade**
Each additional hop increases circuit failure rates. A 7-hop circuit can
experience up to 8% failures, making connections unreliable, compared to
~1% for a standard circuit.
I experience no problems at all. And with SMTP the server acknowledges reception, which means a failed transmission is redone.
**Timing Analysis Vulnerability**
Extended circuits create distinctive timing patterns during their
construction that can be fingerprinted, potentially revealing your
modified client to network monitors.
No proof.
**Compromised Node Paradox**
More hops mean a higher probability of hitting a compromised or
malicious node within the circuit, increasing your overall risk exposure.
You may not know but a single compromised node within a circuit means nothing. But longer circuits immensely reduce the risk of a compromised complete circuit.
Important Security Consideration: Better performance for specific
protocols like email doesn't magically fix the fundamental
fingerprinting vulnerabilities. You are still marking yourself as a
unique user.
You've no idea.
This is not just me saying this but this link also talks about it.
https://www.sciencedirect.com/topics/computer-science/compromised-node
I'm not your nanny. What exactly does it say in this context?
Gabx <info@tcpreset.invalid> wrote:
Stefan Claas <bounce.me@oc2mx.net> wrote:
Anonymous User wrote:
Stefan Claas <bounce.me@oc2mx.net> wrote:
With YAMN's security flaws you can be easily de-anonymized.
Which security flaws? You don't think of Internet I/O which anyhow has to be handled by specialized communication software like OmniMix?
First of all, Zax should IMHO seperate the client form the remailer
code, so that users can focus on one program.
Doesn't look like a problem for OmniMix.
I do not use OmniMix, so I can't speak for it.
So you stir up hatred against it though you're not competent
talking about it. That paints a queer character.
YAMN has the following security flaws:
a) It does not want onion addresses to been used in the MX code
and Zax should really tell us why!
With its advanced delivery strategy OmniMix does a much better
job in forwarding remailer packets than any remailer packet
encoder could ever do.
b) Users new to remailing with YAMN, see only at his repository
minimal configuration files, which are of not much help, IMHO.
Users new to remailing should use a GUI like OmniMix or QS/L.
There's so much that can go wrong. And all that copying &
pasting is boring and prone to errors. Fortunately there's no
reason to reinvent the wheel and learn command line commands.
But the problem is, if you do not look close at his source code
IIRC in config.go, the YAMN client, when set-up not properly,
with socat, can and does bypass your Tor settings in socat and
sends via clearnet to mixmin, filling up his log files and then
crashing his server. Remops know that when analyzing MTA logs
that they include the IP address from the originating client, if
Tor is bypassed, and to whom the email goes. *That is definetily
an absolute no-go* and Zax should explain to us why he coded it
that way for client usage, if users are unaware of this! I am
talking of the internal MXRelay = true setting, which should
be by default set to false in his source code. Mixmaster IIRC
does not do this.
c) Zax should better use Go's proxy package for a seperate
YAMN client, so that stats and pub keys can be fetched via
Tor and also remailing is done via Tor.
OmniMix does all this on its own.
But with YAMN Steve did a great job in packet creation fixing
known Mixmaster flaws and moving to more stylish crypto
algorithms. The rest is of minor importance.
You as a Linux guy should be accustomed to task separation with
a GUI integrating all of those components? OmniMix is just
that.
He should really tell us all, what has driven him to not
like onions, which can be seen IIRC in mail.go.
YAMN in it's current form tells me unfortunately that you
must rely on the old a.p.a-s saying "trust nobody" :-(
Hence the reasone I released yamn-proxy. :-)
But a properly configured MTA would do it as well.
Anonymous User wrote:
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
Yamn2 Remailer wrote:
Stefan Claas <bounce.me@oc2mx.net> wrote:
Anonymous User wrote:
Stefan Claas <bounce.me@oc2mx.net> wrote:
With YAMN's security flaws you can be easily de-anonymized.
Which security flaws? You don't think of Internet I/O which anyhow has >> > > to be handled by specialized communication software like OmniMix?
First of all, Zax should IMHO seperate the client form the remailer
code, so that users can focus on one program.
Doesn't look like a problem for OmniMix.
But who uss OmniMix? Only a handful of a.p.a-s users which
is not the global majority of remailer users.
I do not use OmniMix, so I can't speak for it.
So you stir up hatred against it though you're not competent
talking about it. That paints a queer character.
With using I mean regularly, soory. I have tested a couple of times
of course too.
YAMN has the following security flaws:
a) It does not want onion addresses to been used in the MX code
and Zax should really tell us why!
With its advanced delivery strategy OmniMix does a much better
job in forwarding remailer packets than any remailer packet
encoder could ever do.
See above.
b) Users new to remailing with YAMN, see only at his repository
minimal configuration files, which are of not much help, IMHO.
Users new to remailing should use a GUI like OmniMix or QS/L.
There's so much that can go wrong. And all that copying &
pasting is boring and prone to errors. Fortunately there's no
reason to reinvent the wheel and learn command line commands.
No, they use what they see at GitHub and elsewhere.
But the problem is, if you do not look close at his source code
IIRC in config.go, the YAMN client, when set-up not properly,
with socat, can and does bypass your Tor settings in socat and
sends via clearnet to mixmin, filling up his log files and then
crashing his server. Remops know that when analyzing MTA logs
that they include the IP address from the originating client, if
Tor is bypassed, and to whom the email goes. *That is definetily
an absolute no-go* and Zax should explain to us why he coded it
that way for client usage, if users are unaware of this! I am
talking of the internal MXRelay = true setting, which should
be by default set to false in his source code. Mixmaster IIRC
does not do this.
c) Zax should better use Go's proxy package for a seperate
YAMN client, so that stats and pub keys can be fetched via
Tor and also remailing is done via Tor.
OmniMix does all this on its own.
See above.
But with YAMN Steve did a great job in packet creation fixing
known Mixmaster flaws and moving to more stylish crypto
algorithms. The rest is of minor importance.
You mean this theorethic Ritter's tagging attack?
You as a Linux guy should be accustomed to task separation with
a GUI integrating all of those components? OmniMix is just
that.
Please don't repeat the OmniMix usage.
He should really tell us all, what has driven him to not
like onions, which can be seen IIRC in mail.go.
YAMN in it's current form tells me unfortunately that you
must rely on the old a.p.a-s saying "trust nobody" :-(
Hence the reasone I released yamn-proxy. :-)
But a properly configured MTA would do it as well.
An MTA has nothing to do with what I have described and Zax
owes us an explanation.
But you damned liar repeatedly wrote it is closed-source, which it
isn't. The source code is available, which you asshole know very well.
Meanwhile every participant in this group knows what malicious figures
you and your buddy are. I don't think any further explanations are
required.
Gabx <info@tcpreset.invalid> wrote:
Anonymous User wrote:
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
No, it isn't in the sense of free software, which is good, as you aren't allowed to play around with it and publish forged versions to torpedo development and irritate users.
Anonymous User wrote:
Furthermore, the anonymity of our plain text messages is secured by an >>>>>> extremely weak real-time Tor connection of usually no more than 3 nodes >>>>>> while with OmniMix you're allowed to route your data through much longer >>>>>> Tor circuits and those data aren't plain text but multilayer-encrypted >>>>>> remailer packets.
3 hopes is considered standard enough !
In this group there once was a risk calculation which didn't look very
promising with only 3 hops. I wouldn't bet on it.
Show me that calculation.
it's probably measuring single-node compromise instead of (entry+exit
timing correlation).
If an adversary controls both your entry and exit nodes (the real
threat), they can do timing correlation.
Adding middle hops doesn't defend against that, they still see timing >patterns at entry and exit.
**Behavioral Fingerprinting**
"Using non-standard circuit lengths makes you part of a tiny, easily
identifiable subset. If only 0.1% of Tor users run modified clients, you >>> become statistically unique.
No proof.
You're demanding "proof" while ignoring established research.
Show me YOUR proof that 7-hop circuits are safe. I'll wait.
The Tor Browser Bundle locks down everything (window size, fonts,
JavaScript behavior) specifically to prevent fingerprinting.
Yet you think running 7-hop circuits makes you invisible?
You're making yourself *more* identifiable, not less.
**Failure Cascade**
Each additional hop increases circuit failure rates. A 7-hop circuit can >>> experience up to 8% failures, making connections unreliable, compared to >>> ~1% for a standard circuit.
I experience no problems at all. And with SMTP the server acknowledges
reception, which means a failed transmission is redone.
"I don't notice problems" isn't the same as "problems don't exist".
SMTP retries don't eliminate failures, they mask them.
Your 7-hop circuits are failing and rebuilding more often you don't
notice it because SMTP hides it as "occasional slowness".
**Timing Analysis Vulnerability**
Extended circuits create distinctive timing patterns during their
construction that can be fingerprinted, potentially revealing your
modified client to network monitors.
No proof.
Dude, circuits take time to build.
Yours takes longer because it's 7 hops instead of 3.
Anyone watching network timing can notice it, voila ...
unusual behavior = fingerprint
You may not know but a single compromised node within a circuit means
**Compromised Node Paradox**
More hops mean a higher probability of hitting a compromised or
malicious node within the circuit, increasing your overall risk exposure. >>
nothing. But longer circuits immensely reduce the risk of a compromised
complete circuit.
You're right that one compromised node means nothing.
But wrong about longer circuits helping.
If an adversary controls your entry AND exit, they correlate timing.
Middle nodes don't help.
You're just adding latency and making yourself stand out.
Important Security Consideration: Better performance for specific
protocols like email doesn't magically fix the fundamental
fingerprinting vulnerabilities. You are still marking yourself as a
unique user.
You've no idea.
This is not just me saying this but this link also talks about it.
https://www.sciencedirect.com/topics/computer-science/compromised-node
I'm not your nanny. What exactly does it say in this context?
I'm not your nanny.
What exactly does it say in this context?
Have a reading, conar !!!
You're claiming longer circuits are safer.
I'm asking for proof.
You've provided none.
Just "no proof" responses while ignoring established research.
Show me ONE paper that says custom circuit lengths are *safe*.
Otherwise you're just running on vibes and assumptions.
The guy who doesn't like a webserver on localhost.
Bravo !!!!
Gabx
Stefan Claas wrote:
Yamn2 Remailer wrote:
Stefan Claas <bounce.me@oc2mx.net> wrote:
Anonymous User wrote:
Stefan Claas <bounce.me@oc2mx.net> wrote:
With YAMN's security flaws you can be easily de-anonymized.
Which security flaws? You don't think of Internet I/O which anyhow has
to be handled by specialized communication software like OmniMix?
First of all, Zax should IMHO seperate the client form the remailer code, so that users can focus on one program.
Doesn't look like a problem for OmniMix.
But who uss OmniMix? Only a handful of a.p.a-s users which
is not the global majority of remailer users.
You have user statistics? Interesting.
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
No, it isn't in the sense of free software, which is good, as you aren't >allowed to play around with it and publish forged versions to torpedo >development and irritate users.
Fritz Wuehler wrote:
Gabx <info@tcpreset.invalid> wrote:
Anonymous User wrote:
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
No, it isn't in the sense of free software, which is good, as you aren't
allowed to play around with it and publish forged versions to torpedo
development and irritate users.
The usual Microsoft policy, one foot in every customer segment, to
embrace as many market segments as possible, where the only consistency
is to make more money than the day before.
i had enough of u
i had enough of u
Fritz Wuehler wrote:
Gabx <info@tcpreset.invalid> wrote:
Anonymous User wrote:
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
No, it isn't in the sense of free software, which is good, as you aren't
allowed to play around with it and publish forged versions to torpedo
development and irritate users.
The usual Microsoft policy, one foot in every customer segment, to
embrace as many market segments as possible, where the only consistency
is to make more money than the day before.
i had enough of u
Read the Tor specs and you'll find out that no node gets any information about circuit length.
The Tor Browser Bundle locks down everything (window size, fonts,
JavaScript behavior) specifically to prevent fingerprinting.
Yet you think running 7-hop circuits makes you invisible?
You're making yourself *more* identifiable, not less.
Wrong.
I provided evidence, you contributed nothing.
Fritz Wuehler wrote:
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
No, it isn't in the sense of free software, which is good, as you aren't >>allowed to play around with it and publish forged versions to torpedo >>development and irritate users.
+1
Two decades of solid work. What more has to be said?
Gabx <info@tcpreset.invalid> wrote:
Anonymous User wrote:
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
From the Official Mixmaster Remailer FAQ >(https://mixmaster.sourceforge.net/faq.shtml):
"Running a remailer on Windows is not recommended due to the massive
^^^^^^^
security holes and general lack of stability.
^^^^^^^^ ^^^^^ ^^^^^^^^^^^^^^^^^
UNIX, Linux, or a BSD are recommended, as these systems are generally
free, stable, and relatively secure."
From the Official Mixmaster Remailer FAQ >(https://mixmaster.sourceforge.net/faq.shtml):
"Running a remailer on Windows is not recommended due to the massive
^^^^^^^
security holes and general lack of stability.
^^^^^^^^ ^^^^^ ^^^^^^^^^^^^^^^^^
UNIX, Linux, or a BSD are recommended, as these systems are generally
free, stable, and relatively secure."
Gabx <info@tcpreset.invalid> wrote:
You're claiming longer circuits are safer.
I'm asking for proof.
You've provided none.
Just "no proof" responses while ignoring established research.
I provided evidence, you contributed nothing.
Anonymous User wrote:
Read the Tor specs and you'll find out that no node gets any information
about circuit length.
You're correct that individual nodes cannot determine circuit length
from their position in the chain.
However, you're confusing node-level visibility with network-level >observability.
https://support.torproject.org/misc/misc-11/
The Tor Browser Bundle locks down everything (window size, fonts,
JavaScript behavior) specifically to prevent fingerprinting.
Yet you think running 7-hop circuits makes you invisible?
You're making yourself *more* identifiable, not less.
Wrong.
You keep ignoring actual research:
- USENIX Security 2015: "Circuit Fingerprinting Attacks" 98%+ accuracy
in identifying non-standard circuits.
- Traffic analysis can distinguish modified circuits even when
application traffic is identical.
I provided evidence, you contributed nothing.
Blagger
Non-standard circuits are fingerprint-able with 98%+ accuracy.
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kwon
You demanded proof. There it is.
Official Tor Project says you're wrong. Academic research confirms it.
Show me ONE official Tor document recommending 7-hop circuits.
You fundamentally misunderstand hidden service architecture.
Yes, I control three hidden services: SMTP gateway, mail2news, and NNTP >server.
But I control just the application endpoints, not the the Tor circuits.
Conar !!!
Gabx
Fritz Wuehler wrote:
Gabx <info@tcpreset.invalid> wrote:
Anonymous User wrote:
Gabx <info@tcpreset.invalid> wrote:
And Omnimix is NOT Opensource !
No, I'm not a liar.
My beloved conar.
From the Official Mixmaster Remailer FAQ
(https://mixmaster.sourceforge.net/faq.shtml):
"Running a remailer on Windows is not recommended due to the massive >security holes and general lack of stability.
UNIX, Linux, or a BSD are recommended, as these systems are generally
free, stable, and relatively secure."
But this is just a small example, should we give it any importance?
It must be left hand propaganda isn't it?
You're running anonymous remailer software on an operating system that:
1. Records your keystrokes (telemetry)
2. Sends usage data to Microsoft
3. Cannot be fully audited (closed source)
4. Is explicitly not recommended by Mixmaster documentation
So we have:
- Closed-source OS (Windows)
- Closed-source remailer (OmniMix)
- Zero independent security audits possible
- Complete opacity
According to Microsoft's own documentation >https://learn.microsoft.com/en-us/windows/privacy/configure-windows-diagnostic-data-in-your-organization
https://www.eff.org/deeplinks/2016/08/windows-10-microsoft-blatantly-disregards-user-choice-and-privacy-deep-dive
Omnimix is not opensource.
PRISM Break is a project that lists privacy-focused, open-source >alternatives.
OmniMix was explicitly rejected because it doesn't meet the open-source >criteria.
A direct quote from Zegnat maintainer of PRISM Break >https://github.com/prism-break/prism-break/issues/1469
- "I can right now say it will not be included on PRISM Break. It is not >open-source in any way. You are not allowed to create derivative works
at all."
- Includes "License.txt (License agreement)" with "legal limitations"
- Copyright: Christian Danner, 2025
- There is no OSI-approved or FSF-approved license
- No official GitHub repository for OmniMix.
- No SourceForge repository
- Contrast with Mixmaster: https://github.com/eurovibes/mixmaster (open >source)
"Free for private use" means **proprietary freeware**.
You can't:
- Modify the code
- Create derivative works
- Redistribute modified versions
- Independently audit for backdoors or vulnerabilities ( security you know?)
From the official website:
- Source code available for peer review
- Not available for modification or derivative works
- Restrictions in License.txt (not publicly available)
Key difference:
- Open Source = code available + freedom to modify/redistribute
- OmniMix = code available + NO freedom to modify
The "Source Available" Fallacy.
Yes, you can view some source code "for peer review."
But as the PRISM Break maintainer correctly notes: having viewable
source code doesn't make it open source.
You're being asked to trust your anonymity to:
1. A closed-source OS (Windows)
2. A proprietary application (OmniMix)
3. With no independent security audits possible
4. No ability to verify what the code actually does
5. No community review or hardening
This is the opposite of security best practices.
With open source software like Mixmaster, the community can audit the
code, find vulnerabilities, and verify there are no backdoors.
With proprietary software like OmniMix?
You're trusting one developer.
The difference between "source available" and "open source" isn't
semantics.
Gabx
Anonymous User <noreply@dirge.harmsk.com> wrote:
Gabx <info@tcpreset.invalid> wrote:
You're claiming longer circuits are safer.
I'm asking for proof.
You've provided none.
Just "no proof" responses while ignoring established research.
I provided evidence, you contributed nothing.
I understand Gabx's confusion. OmniMix uses Tor only to deliver
packets to the remailer network, a task of minor importance
concerning anonymity, and you have the choice of creating longer
circuits or not.
An untrustworthy OmniMix user wrote:
Anonymous User <noreply@dirge.harmsk.com> wrote:
Gabx <info@tcpreset.invalid> wrote:
You're claiming longer circuits are safer.
I'm asking for proof.
You've provided none.
Just "no proof" responses while ignoring established research.
I provided evidence, you contributed nothing.
I understand Gabx's confusion. OmniMix uses Tor only to deliver
packets to the remailer network, a task of minor importance
concerning anonymity, and you have the choice of creating longer
circuits or not.
A task of minor importance? You would shit your pants if you didn't
use Tor with OmniMix because you don't trust the remailer operators,
as they can be pressured and the remailer traffic of these public
mini networks can be completely monitored.
Radio Eriwan <noreply@radio-eriwan.ru> wrote:
An untrustworthy OmniMix user wrote:
Anonymous User <noreply@dirge.harmsk.com> wrote:
Gabx <info@tcpreset.invalid> wrote:
You're claiming longer circuits are safer.
I'm asking for proof.
You've provided none.
Just "no proof" responses while ignoring established research.
I provided evidence, you contributed nothing.
I understand Gabx's confusion. OmniMix uses Tor only to deliver
packets to the remailer network, a task of minor importance
concerning anonymity, and you have the choice of creating longer
circuits or not.
A task of minor importance? You would shit your pants if you didn't
use Tor with OmniMix because you don't trust the remailer operators,
as they can be pressured and the remailer traffic of these public
mini networks can be completely monitored.
Learn about Type II Remailer networks. For an external adversary
there's nothing to win.
Another untrustworthy OmniMix User wrote:
Radio Eriwan <noreply@radio-eriwan.ru> wrote:
An untrustworthy OmniMix user wrote:
Anonymous User <noreply@dirge.harmsk.com> wrote:
Gabx <info@tcpreset.invalid> wrote:
You're claiming longer circuits are safer.
I'm asking for proof.
You've provided none.
Just "no proof" responses while ignoring established research.
I provided evidence, you contributed nothing.
I understand Gabx's confusion. OmniMix uses Tor only to deliver
packets to the remailer network, a task of minor importance
concerning anonymity, and you have the choice of creating longer
circuits or not.
A task of minor importance? You would shit your pants if you didn't
use Tor with OmniMix because you don't trust the remailer operators,
as they can be pressured and the remailer traffic of these public
mini networks can be completely monitored.
Learn about Type II Remailer networks. For an external adversary
there's nothing to win.
Utterly nonsense! And you know that very well!
An untrustworthy OmniMix user wrote:
Anonymous User <noreply@dirge.harmsk.com> wrote:
Gabx <info@tcpreset.invalid> wrote:
You're claiming longer circuits are safer.
I'm asking for proof.
You've provided none.
Just "no proof" responses while ignoring established research.
I provided evidence, you contributed nothing.
I understand Gabx's confusion. OmniMix uses Tor only to deliver
packets to the remailer network, a task of minor importance
concerning anonymity, and you have the choice of creating longer
circuits or not.
A task of minor importance? You would shit your pants if you didn't
use Tor with OmniMix because you don't trust the remailer operators,
as they can be pressured and the remailer traffic of these public
mini networks can be completely monitored.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 54 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 17:44:54 |
| Calls: | 742 |
| Files: | 1,218 |
| D/L today: |
4 files (8,203K bytes) |
| Messages: | 184,414 |
| Posted today: | 1 |