From Newsgroup: alt.privacy

When using hsubs in a.a.m is it secure against rainbow attacks?

Are hsubs, esubs in a.a.m secure against replay attacks?

Would you call it nowadays anonymous remailing, when the
remailer IP addresses are publicity known to third parties,
compared to tor hidden services mailer infrastructures,
where mailing is truly anonymous and without knowing the
sender/receiver addresses, thanks to ORBs?

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

On Fri, 20 Jun 2025 20:00:47 +0000, Mini Mailer
<bounce.me@mini.mailer.msg> wrote:

When using hsubs in a.a.m is it secure against rainbow attacks?

I deliberately misspell some words in my passphrases.

Are hsubs, esubs in a.a.m secure against replay attacks?

Would you call it nowadays anonymous remailing, when the
remailer IP addresses are publicity known to third parties,

Using Tor with QSL hides your IP even from entry remailer.

compared to tor hidden services mailer infrastructures,
where mailing is truly anonymous and without knowing the
sender/receiver addresses, thanks to ORBs?

Never heard of ORBs.
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Claas once again spams disinformation:

When using hsubs in a.a.m is it secure against rainbow attacks?

Yes, it's secure, as they aren't vulnerable to such attacks.

Are hsubs, esubs in a.a.m secure against replay attacks?

Yes, they are perfectly secure when you download the complete feed and
then process your messages locally.

Less secure would be adding dummy downloads combined with a distributed
message retrieval from multiple servers through Tor, a strategy relevant
with low-bandwidth connections.

Would you call it nowadays anonymous remailing, when the
remailer IP addresses are publicity known to third parties,

Sure. That question once again tells us that you don't have a clue.

compared to tor hidden services mailer infrastructures,
where mailing is truly anonymous and without knowing the
sender/receiver addresses, thanks to ORBs?

Wrong. That's exactly the fundamental problem with ORBs, which know your address, whereas nym reply blocks ending at a.a.m simply don't!

So shove your BS up your a?? before you FOAD!

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous still defending (as usual) old tech, wrote:

Claas once again spams disinformation:

When using hsubs in a.a.m is it secure against rainbow attacks?

Yes, it's secure, as they aren't vulnerable to such attacks.

https://rittervg.com/p/AAM-defcon13.pdf

So, Ritter's GPU cracker, for hsub, did not used then rainbow tables?

Are hsubs, esubs in a.a.m secure against replay attacks?

Yes, they are perfectly secure when you download the complete feed and
then process your messages locally.

Less secure would be adding dummy downloads combined with a distributed message retrieval from multiple servers through Tor, a strategy relevant
with low-bandwidth connections.

You are telling us, that a.a.m software has something like a replay cache,
to filter many hsubs/esubs, injected with the same collected hex strings?

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Mini Mailer wrote:

Anonymous still defending (as usual) old tech, wrote:

Claas once again spams disinformation:

When using hsubs in a.a.m is it secure against rainbow attacks?

Yes, it's secure, as they aren't vulnerable to such attacks.

https://rittervg.com/p/AAM-defcon13.pdf

So, Ritter's GPU cracker, for hsub, did not used then rainbow tables?

Are hsubs, esubs in a.a.m secure against replay attacks?

Yes, they are perfectly secure when you download the complete feed and
then process your messages locally.

Less secure would be adding dummy downloads combined with a distributed message retrieval from multiple servers through Tor, a strategy relevant with low-bandwidth connections.

You are telling us, that a.a.m software has something like a replay cache,
to filter many hsubs/esubs, injected with the same collected hex strings?

Optional replay cache with database support added. :-)

https://github.com/Ch1ffr3punk/f-esub

Regards
Stefan
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

ted@invalid.net wrote:

Never heard of ORBs.

ORBs are pretty cool, if you run your own email infrastructure
with family, friends and co-workers, so that you don't need to
trust unreliable third-party and outdated remailer networks.

https://github.com/Ch1ffr3punk/pluto
https://tilde.club/~pollux/

Regards
Stefan


--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

So shove your BS up your a?? before you FOAD!

You and your LEA supporting team are only pissed,
because you can't control nor monitor Mini Mailer,
smtpdump and pluto, global and decentralized Tor
Hidden Services networks, like you can do with
outdated public store and forwarding mini remailer
networks. :-D

Regards
Stefan



--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Claas wrote:

Anonymous still defending (as usual) old tech, wrote:

Claas once again spams disinformation:

When using hsubs in a.a.m is it secure against rainbow attacks?

Yes, it's secure, as they aren't vulnerable to such attacks.

https://rittervg.com/p/AAM-defcon13.pdf

So, Ritter's GPU cracker, for hsub, did not used then rainbow tables?

Correct. AFAICS that's a brute force attack. But where's the source
code? And look how short the broken subjects are. That's a joke.

| I found an interesting set of messages with the hsub DANGER WILL ROBINSON,
| which was used by some, but of all, of the messages to a couple of
| particular KeyIDs.
|
| I cracked all the hsubs of another Key ID, with the two passwords
| testicular and panties.
|
| If you don’t know what schmegma is, don’t urban dictionary it.

And here's an example of Omnimix "mantras":

| Seed:
| gOZDZ4MymZ4gb9uXf9ZwF1Nw+5/C7nCvRbvxEr59qjw
|
| Remailer Mantras ([nym server ...] exit remailer / slot 11):
| MK0YencSvf8ti4XfeLV74E1xAJaQTfXm9CSoAd6bJPo
| JChbngCDpyQR0SzX661Ltvu423ZJ1CFOC5okUHZvc08
| G+90lafZ8t5t9soNork9zOCnCRpRnWf88jK5WyKsbrk
| seeQc2SE0tlNL4plKGWTWra1KivuSdO1fEss6OFvo/k
|
| Esub Mantra:
| nzLozyHAk60llgtE4UjMW6FELiInr60WXrQvJsypHGs

Have fun with it, particularly with building a rainbow table. LOL!

Are hsubs, esubs in a.a.m secure against replay attacks?

Yes, they are perfectly secure when you download the complete feed and
then process your messages locally.

Less secure would be adding dummy downloads combined with a distributed
message retrieval from multiple servers through Tor, a strategy relevant
with low-bandwidth connections.

You are telling us, that a.a.m software has something like a replay cache,
to filter many hsubs/esubs, injected with the same collected hex strings?

No, I'm not. And there's no reason to implement such a cache, as the user
has to know that he's under attack. Furthermore, as all messages are
processed locally, an attacker will never know about the extensive
processing.

So FO!

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

You are telling us, that a.a.m software has something like a replay cache, to filter many hsubs/esubs, injected with the same collected hex strings?

No, I'm not. And there's no reason to implement such a cache, as the user has to know that he's under attack. Furthermore, as all messages are processed locally, an attacker will never know about the extensive processing.

What does the user gain from it when he knows that he is under an attack?
And what can he do to not get such unwanted messages to process?

Regards
Stefan

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

In article <10366o4$1bvtl$2@news.tcpreset.net> Stefan Claas announced:

Mini Mailer wrote:

Anonymous still defending (as usual) old tech, wrote:

Claas once again spams disinformation:

When using hsubs in a.a.m is it secure against rainbow attacks?

Yes, it's secure, as they aren't vulnerable to such attacks.

https://rittervg.com/p/AAM-defcon13.pdf

So, Ritter's GPU cracker, for hsub, did not used then rainbow tables?

Are hsubs, esubs in a.a.m secure against replay attacks?

Yes, they are perfectly secure when you download the complete feed and
then process your messages locally.

Less secure would be adding dummy downloads combined with a distributed
message retrieval from multiple servers through Tor, a strategy relevant >>> with low-bandwidth connections.

You are telling us, that a.a.m software has something like a replay cache, >> to filter many hsubs/esubs, injected with the same collected hex strings?

Optional replay cache with database support added. :-)

https://github.com/Ch1ffr3punk/f-esub

Stefan, that truly is an important measure to avoid the effort of
decoding other's a.a.m replies twice. You're absolutely on the
right track to something really great! Keep it up! We're with you.

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Nomen Nescio wrote:

In article <10366o4$1bvtl$2@news.tcpreset.net> Stefan Claas announced:

Optional replay cache with database support added. :-)

https://github.com/Ch1ffr3punk/f-esub

Stefan, that truly is an important measure to avoid the effort of
decoding other's a.a.m replies twice. You're absolutely on the
right track to something really great! Keep it up! We're with you.

Thank you, much appreciated! Please note, in order that this works
you will also need my new e-sub program, which uses modern crypto,
but blends with the old e-sub Subjects: too.

https://github.com/Ch1ffr3punk/esub

Regards
Stefan


--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Claas wrote:

Anonymous wrote:

You are telling us, that a.a.m software has something like a replay cache, >> > to filter many hsubs/esubs, injected with the same collected hex strings? >>

No, I'm not. And there's no reason to implement such a cache, as the user >> has to know that he's under attack. Furthermore, as all messages are
processed locally, an attacker will never know about the extensive
processing.

What does the user gain from it when he knows that he is under an attack?

You're joking, aren't you?

And what can he do to not get such unwanted messages to process?

Get in touch with the attacker to convince him to stop it? ;-)

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

Claas wrote:

Anonymous wrote:

You are telling us, that a.a.m software has something like a replay cache,
to filter many hsubs/esubs, injected with the same collected hex strings?

No, I'm not. And there's no reason to implement such a cache, as the user
has to know that he's under attack. Furthermore, as all messages are processed locally, an attacker will never know about the extensive processing.

What does the user gain from it when he knows that he is under an attack?

You're joking, aren't you?

In regards to a.a.m. no, I am not joking. But... he does not know, when under
a Pegasus/FinSpy attack, if using online tools like Omnimix. So better one prepares his stuff offline and then inject it later online for a.a.m. usage.

Same goes for fetching from a.a.m.

Regards
Stefan


--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Stefan Claas dreams:

Anonymous wrote:

So shove your BS up your a?? before you FOAD!

+1

You and your LEA supporting team are only pissed,
because you can't control nor monitor Mini Mailer,
smtpdump and pluto, global and decentralized Tor
Hidden Services networks, like you can do with
outdated public store and forwarding mini remailer
networks. :-D

-1

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Fritz Wuehler wrote:

Stefan Claas dreams:

[...]

I am currently dreaming of Chinese AI beating U.S. stylometry ...,
so called adversarial stylometry. :-) Let's see what I can come up
with in the future.

Long live Eurasia! :-)

Regards
Stefan
--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Claas wrote:

Anonymous wrote:

Claas wrote:

Anonymous wrote:

You are telling us, that a.a.m software has something like a replay cache,
to filter many hsubs/esubs, injected with the same collected hex strings?

No, I'm not. And there's no reason to implement such a cache, as the user
has to know that he's under attack. Furthermore, as all messages are
processed locally, an attacker will never know about the extensive
processing.

What does the user gain from it when he knows that he is under an attack? >>

You're joking, aren't you?

In regards to a.a.m. no, I am not joking.

So you're not interested in knowing whether you're under attack? That's stupid.

But... he does not know, when under
a Pegasus/FinSpy attack, if using online tools like Omnimix. So better one >prepares his stuff offline and then inject it later online for a.a.m. usage.

For a.a.m usage? What's that?

BTW, simply set Display -> Shorten Msg to 0 on your offline OM and copy
the MM/YAMN output from Rem Data into files. But don't forget to update
your offline OM's statistics files every now and then to get reliable
chains.

Same goes for fetching from a.a.m.

I'm sure there'll also be ways to get an offline database of the a.a.m
group.

--- Synchronet 3.21e-Win32 NewsLink 1.2

From Newsgroup: alt.privacy

Anonymous wrote:

Claas wrote:

Anonymous wrote:

Claas wrote:

Anonymous wrote:

You are telling us, that a.a.m software has something like a replay cache,
to filter many hsubs/esubs, injected with the same collected hex strings?

No, I'm not. And there's no reason to implement such a cache, as the user
has to know that he's under attack. Furthermore, as all messages are processed locally, an attacker will never know about the extensive processing.

What does the user gain from it when he knows that he is under an attack?

You're joking, aren't you?

In regards to a.a.m. no, I am not joking.

So you're not interested in knowing whether you're under attack? That's stupid.

Why, when using a.a.m. with a replay cache I do not have to worry about
an attack, because the attack(s) become useless.

But... he does not know, when under
a Pegasus/FinSpy attack, if using online tools like Omnimix. So better one prepares his stuff offline and then inject it later online for a.a.m. usage.

For a.a.m usage? What's that?

Pegasus from Israel and FynSpy from Germany are Government trojans which
your device, whether your Windows, Mac, Linux or mobile AV, can't detect.

BTW, simply set Display -> Shorten Msg to 0 on your offline OM and copy
the MM/YAMN output from Rem Data into files. But don't forget to update
your offline OM's statistics files every now and then to get reliable
chains.

I do not use Omnimix or QSL. In the past I have always used pure Mixmaster
or YAMN, along with socat and Tor.

Same goes for fetching from a.a.m.

I'm sure there'll also be ways to get an offline database of the a.a.m
group.

My NewsWatcher program is designed to fetch all articles from a Usenet
group and then one can later use my f-esub program, with a replay cache
option, to extract all messages for a given user, on his offline device.

Regards
Stefan
--- Synchronet 3.21e-Win32 NewsLink 1.2