Nofuture-Buddy Web Interface at safecomms (victor)

[Gabx]

Nofuture is a web application to use with the browser.

When in one tab you have a chat F4c3b00k, in the other tab there is nofuture.

In the first tab, with your interlocutor you decide to have a secret communication.

In the second tab, the nofuture one, you and your interlocutor start a session.

This will produce a session code, which you will share with your interlocutor and a pair of keys.
Once you receive the session code from your interlocutor, both of you can start pairing your sessions.

This will allow both of you to encrypt and decrypt text.
Text that you will copy and paste to and from the chat you are using.

It is like a crypto text plugin not integrated into your mainstream chat.

The keys are generated on our server and kept in ram.
At the end of the session they will be deleted forever.
For a new conversation you will have to generate a new session and therefore new keys.
In technical terms it is called ZeroTrust, I called it nofuture, at the end of the session nofuture decryption.
The purpose is to leave encrypted conversations inside mainstream chats for which the keys that generated them and that decrypt them no longer exist.

Nofuture is open for testing.

I'd like to know user experiences to make it better.

Share your experience here.

Best regards

Gabx

Nofuture-Buddy:
https://safecomms.virebent.art

[Richard Heathfield]

On 06/02/2025 09:36, Gabx wrote:
> Nofuture is a web application to use with the browser.
>
> When in one tab you have a chat F4c3b00k, in the other tab there is nofuture.
>
> In the first tab, with your interlocutor you decide to have a secret communication.
>
> In the second tab, the nofuture one, you and your interlocutor start a session.
>
> This will produce a session code, which you will share with your interlocutor and a pair of keys.
> Once you receive the session code from your interlocutor, both of you can start pairing your sessions.
>
> This will allow both of you to encrypt and decrypt text.

And the key provider. Let's just hope he or she is trustworthy, eh?

> Text that you will copy and paste to and from the chat you are using.
>
> It is like a crypto text plugin not integrated into your mainstream chat.
>
> The keys are generated on our server and kept in ram.
> At the end of the session they will be deleted forever.

Honest, guv...

> For a new conversation you will have to generate a new session and therefore new keys.
> In technical terms it is called ZeroTrust,

For something called ZeroTrust it seems to require a level of
trust best described as "gullible".

> I called it nofuture, at the end of the session nofuture decryption.
> The purpose is to leave encrypted conversations inside mainstream chats for which the keys that generated them and that decrypt them no longer exist.

Except for people who keep copies.

> Nofuture is open for testing.
>
> I'd like to know user experiences to make it better.
>
> Share your experience here.

Diffie-Hellman for keys and AES for encryption.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Stefan Claas]

Richard Heathfield wrote:
> On 06/02/2025 09:36, Gabx wrote:

> > Share your experience here.
>
> Diffie-Hellman for keys and AES for encryption.

That's what I am using too. And no web ussage needed.

https://github.com/706f6c6c7578/minitalk

Regards
Stefan

--
Onion Courier Home Server Mon-Fri 15:00-21:00 UTC Sat-Sun 11:00-21:00 UTC
ohpmsq5ypuw5nagt2jidfyq72jvgw3fdvq37txhnm5rfbhwuosftzuyd.onion:8080 inbox
age1yubikey1qv5z678j0apqhd4ng7p22g4da8vxy3q5uvthg6su76yj0y8v7wp5kvhstum

[Gabx]

Richard Heathfield wrote:> On 06/02/2025 09:36, Gabx wrote:
>
> And the key provider. Let's just hope he or she is trustworthy, eh?

This is a testing experience.
In future releases i will add cryptography.fernet and/or mmap.
Fernet crypts all tipes of data in ram while mmap avoids disk writes.

>>
>> The keys are generated on our server and kept in ram.
>> At the end of the session they will be deleted forever.
>
> Honest, guv...

?
I'm lost on this.

>
> Except for people who keep copies.

we don't force anyone to do it
I had an idea.
Should I invite them to write on our cryptpad.virebent.art ?

> Diffie-Hellman for keys and AES for encryption.
>

When you call /start_session, it creates a new Ed25519 private key and corresponding public key, these Ed25519 keys are primarily used for signing.

Internally, the script converts the Ed25519 private key to an X25519 private key.

This X25519 key is used for ECDH (Elliptic-Curve Diffie–Hellman) key agreement with the peer’s X25519 public key.

Once the ephemeral X25519 ECDH handshake is done, the script uses HKDF (a key-derivation function) to derive a 32-byte key.
That key is then used for AES-256-GCM encryption.

After encryption with AES-256-GCM, the ciphertext is signed with the ephemeral Ed25519 private key.
The receiving side verifies that signature using the sender’s Ed25519 public key.

https://github.com/gabrix73/Nofuture-Buddy.git

Gabx

https://safecomms.virebent.art

[Richard Heathfield]

On 06/02/2025 14:56, Gabx wrote:
> Richard Heathfield wrote:> On 06/02/2025 09:36, Gabx wrote:
>>
>> And the key provider. Let's just hope he or she is trustworthy, eh?
>
> This is a testing experience.

Your response fails to address the trust issue.

> In future releases i will add cryptography.fernet and/or mmap.
> Fernet crypts all tipes of data in ram while mmap avoids disk writes.
>
>>>
>>> The keys are generated on our server and kept in ram.
>>> At the end of the session they will be deleted forever.
>>
>> Honest, guv...
>
> ?
> I'm lost on this.

To clarify, then: Your response fails to address the trust issue.

>> Except for people who keep copies.
>
> we don't force anyone to do it
> I had an idea.
> Should I invite them to write on our cryptpad.virebent.art ?

You could invite them to send you their debit card PINs and their
home addresses. To clarify, your response fails to address the
trust issue.

You are asking people to commit sensitive information to your
software's care and expecting them to trust that you won't take a
peek. Why should anyone trust you?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[D]

On Thu, 6 Feb 2025 16:42:00 +0000, Richard Heathfield <***@cpax.org.uk> wrote:
>On 06/02/2025 14:56, Gabx wrote:
>> Richard Heathfield wrote:> On 06/02/2025 09:36, Gabx wrote:
>>> And the key provider. Let's just hope he or she is trustworthy, eh?
>>
>> This is a testing experience.
>
>Your response fails to address the trust issue.
>
>> In future releases i will add cryptography.fernet and/or mmap.
>> Fernet crypts all tipes of data in ram while mmap avoids disk writes.
>>
>>>> The keys are generated on our server and kept in ram.
>>>> At the end of the session they will be deleted forever.
>>>
>>> Honest, guv...
>>
>> I'm lost on this.
>
>To clarify, then: Your response fails to address the trust issue.
>
>>> Except for people who keep copies.
>>
>> we don't force anyone to do it
>> I had an idea.
>> Should I invite them to write on our cryptpad.virebent.art ?
>
>You could invite them to send you their debit card PINs and their
>home addresses. To clarify, your response fails to address the
>trust issue.
>You are asking people to commit sensitive information to your
>software's care and expecting them to trust that you won't take a
>peek. Why should anyone trust you?

promoters and supporters of "safe" alternatives to traditional usage
of anonymous remailers either 1) don't understand that not all users
of remailers are casual experimenters, hobbyists, curious, newcomers,
and so forth that have little to lose where big brother is concerned;
or 2) they fully understand the risks which is why they're promoting
what appears to be a storefront operation meant to entrap the unwary

rumor has it that some remailer users actually take serious risks in
the world of encrypted communication, where even the tiniest mistake
could prove fatal or worse . . . probably most of us have nothing to
worry about like johnny rivers "secret agent man" lyrics warns about,
but it's possible that remailer users that can't take deadly chances

[Onion Courier]

In message <***@mixmin.net> D wrote:
> On Thu, 6 Feb 2025 16:42:00 +0000, Richard Heathfield <***@cpax.org.uk> wrote:
> > On 06/02/2025 14:56, Gabx wrote:
> > > Richard Heathfield wrote:> On 06/02/2025 09:36, Gabx wrote:
> > > > And the key provider. Let's just hope he or she is trustworthy, eh?
> > >
> > > This is a testing experience.
> >
> > Your response fails to address the trust issue.
> >
> > > In future releases i will add cryptography.fernet and/or mmap.
> > > Fernet crypts all tipes of data in ram while mmap avoids disk writes.
> > >
> > > > > The keys are generated on our server and kept in ram.
> > > > > At the end of the session they will be deleted forever.
> > > >
> > > > Honest, guv...
> > >
> > > I'm lost on this.
> >
> > To clarify, then: Your response fails to address the trust issue.
> >
> > > > Except for people who keep copies.
> > >
> > > we don't force anyone to do it
> > > I had an idea.
> > > Should I invite them to write on our cryptpad.virebent.art ?
> >
> > You could invite them to send you their debit card PINs and their
> > home addresses. To clarify, your response fails to address the
> > trust issue.
> > You are asking people to commit sensitive information to your
> > software's care and expecting them to trust that you won't take a
> > peek. Why should anyone trust you?
>
> promoters and supporters of "safe" alternatives to traditional usage
> of anonymous remailers either 1) don't understand that not all users
> of remailers are casual experimenters, hobbyists, curious, newcomers,
> and so forth that have little to lose where big brother is concerned;
> or 2) they fully understand the risks which is why they're promoting
> what appears to be a storefront operation meant to entrap the unwary
>
> rumor has it that some remailer users actually take serious risks in
> the world of encrypted communication, where even the tiniest mistake
> could prove fatal or worse . . . probably most of us have nothing to
> worry about like johnny rivers "secret agent man" lyrics warns about,
> but it's possible that remailer users that can't take deadly chances
>

promoters and supporters of "safe" alternatives to traditional usage
of anonymous remailers understand very well that traditional anonymous
remailer usage can be very dangerous, when a) using, like you, OmniMix
only with an online PC and then promoting also b) , from so called
experts, nobody knows, the usage of WME, on an online PC!

BTW. Do you know by chance why so many apas users have disappeared over
the years, while using traditional remailers, which needs operators and
pingers in order to work and can possibly store messages for a Long
period of time, ideally suited for eclipse attacks, because IP addresses
from the "anonymous" remailer network are publicity known, including the
destination email address, or long time storage (for later decryption)
Usenet Group alt.anonymous.messages?

[Yamn2 Remailer]

On Thu, 6 Feb 2025 21:09:42 +0000 (UTC), Onion Courier wrote:


>promoters and supporters of "safe" alternatives to traditional usage
>of anonymous remailers understand very well that traditional anonymous
>remailer usage can be very dangerous, when a) using, like you, OmniMix
>only with an online PC and then promoting also b) , from so called
>experts, nobody knows, the usage of WME, on an online PC!


OmniMix is the transport engine, which doesn't make sense on an offline
device. But you're free to encrypt the workload additionally in advance
on an offline computer.


>
>BTW. Do you know by chance why so many apas users have disappeared over
>the years, while using traditional remailers, which needs operators and
>pingers in order to work and can possibly store messages for a Long
>period of time, ideally suited for eclipse attacks, because IP addresses
>from the "anonymous" remailer network are publicity known, including the
>destination email address, or long time storage (for later decryption)
>Usenet Group alt.anonymous.messages?


To see messages end up at a newsgroup or a nym account. Big deal!

All in all you have to crack about six remailer keys and three up to
possibly nine Tor node keys. Good luck with it!

Now compare that with the amateurish system you promote.

[Onion Courier]

In message <***@mixmin.net> Yamn2 Remailer wrote:

> All in all you have to crack about six remailer keys and three up to
> possibly nine Tor node keys. Good luck with it!

You don't have to crack remailer keys, they are freely available
on VPS servers for an eclipse attack. Same applies for Tor nodes :)

> Now compare that with the amateurish system you promote.

I am not promoting a No Future-Buddy Web Interface, but D’s
claims required a response. ;)

[Anonymous]

Onion Courier <***@oc2mx.net> wrote:
> In message <***@mixmin.net> Yamn2 Remailer wrote:
>
>> All in all you have to crack about six remailer keys and three up to
>> possibly nine Tor node keys. Good luck with it!
>
> You don't have to crack remailer keys, they are freely available
> on VPS servers for an eclipse attack. Same applies for Tor nodes :)

Hard to imagine an eclipse attack isolating all nodes of a circuit
followed by all remailers of a chain worldwide in sequence starting at a
suspicious sender, which also has to be done within the tight timeframe
determined by their key invalidation policies. Furthermore, you really
think such network manipulations won't be detected? Looks like a pipe
dream.

[Onion Courier]

In message <***@remailer.paranoici.org> Anonymous wrote:

> Onion Courier <***@oc2mx.net> wrote:
> > In message <***@mixmin.net> Yamn2 Remailer wrote:
> >
> > > All in all you have to crack about six remailer keys and three up to
> > > possibly nine Tor node keys. Good luck with it!
> >
> > You don't have to crack remailer keys, they are freely available
> > on VPS servers for an eclipse attack. Same applies for Tor nodes :)
>
> Hard to imagine an eclipse attack isolating all nodes of a circuit
> followed by all remailers of a chain worldwide in sequence starting at a
> suspicious sender, which also has to be done within the tight timeframe
> determined by their key invalidation policies. Furthermore, you really
> think such network manipulations won't be detected? Looks like a pipe
> dream.
>
I would not underestimate TLAs that send a gag order to ISPs and VPS Providers,
in the West. Take OmniMix under Windows, for example, which D uses. OmniMix does
not use standard Tor ports and so TLAs, in cooperation with ISPs, can put a small
state trojan on his computer, because he is using the Tor network, without him
noticing and they then receive what time of day he is using OmniMix tor.exe
and not Tor Browser or Tor Expert Bundle tor.exe.

They do not even need to worry about the Tor nodes, as they know that remops does
not have an SOP that tells them how to secure their remailers against their VPS
providers.

They can also receive the passwords for a.a.m via gag order, as nym servers hold
them. This leaves only an asymmetric message in a.a.m which announces the key ID
and UID and then uses this to cross-check the same on online home PCs are being
monitored.

Remailer users also do not know any warrant canaries from their remailer/nym server
operators who could possibly keep them updated.

[Onion Courier]

Onion Courier wrote:

> I would not underestimate TLAs that send a gag order to ISPs and VPS Providers,
> in the West. Take OmniMix under Windows, for example, which D uses. OmniMix does
> not use standard Tor ports and so TLAs, in cooperation with ISPs, can put a small
> state trojan on his computer, because he is using the Tor network, without him
> noticing and they then receive what time of day he is using OmniMix tor.exe
> and not Tor Browser or Tor Expert Bundle tor.exe.

Do not forget "snow" like GnuPG tagging attacks, which GnuPG can't detect and which
identifies Bob as sender of an anonymous symmetric only encrypted message to Alice.

[Camouflage]

In article <***@hal.oc2mx.net> Onion Courier wrote:
>In message <***@remailer.paranoici.org> Anonymous wrote:
>
>> Onion Courier <***@oc2mx.net> wrote:
>> > In message <***@mixmin.net> Yamn2 Remailer wrote:
>> >
>> > > All in all you have to crack about six remailer keys and three up to
>> > > possibly nine Tor node keys. Good luck with it!
>> >
>> > You don't have to crack remailer keys, they are freely available
>> > on VPS servers for an eclipse attack. Same applies for Tor nodes :)
>>
>> Hard to imagine an eclipse attack isolating all nodes of a circuit
>> followed by all remailers of a chain worldwide in sequence starting at a
>> suspicious sender, which also has to be done within the tight timeframe
>> determined by their key invalidation policies. Furthermore, you really
>> think such network manipulations won't be detected? Looks like a pipe
>> dream.
>>
>I would not underestimate TLAs that send a gag order to ISPs and VPS Providers,
>in the West.

Any example? And feel free to route your Tor traffic through nodes not
under Western control (<https://tormap.org/>).

> Take OmniMix under Windows, for example, which D uses. OmniMix does
>not use standard Tor ports

Please explain. Which non-standard ports?

> and so TLAs, in cooperation with ISPs, can put a small
>state trojan on his computer, because he is using the Tor network, without him
>noticing and they then receive what time of day he is using OmniMix tor.exe
>and not Tor Browser or Tor Expert Bundle tor.exe.

After a successful intrusion they just record Tor usage? LOL! And how
about those who use the same Tor instance for Omnimix as well as the Tor
Browser? BTW, here Omnimix runs 24/7 sending dummy messages at irregular
intervals.

>
>They do not even need to worry about the Tor nodes, as they know that remops does
>not have an SOP that tells them how to secure their remailers against their VPS
>providers.

No doubt, I'd also prefer remailers hosted at secure sites.

>
>They can also receive the passwords for a.a.m

Please explain. Passwords for a.a.m?

> via gag order, as nym servers hold
>them.

Apart from the account's public key the nymserver only knows the symmetric
password it has to use to encrypt the message before sending it to each
reply block's cypherpunk entry remailer. Only the Cypherpunk exits know
about their individual subject encoding parameters.

> This leaves only an asymmetric message in a.a.m which announces the key ID
>and UID and then uses this to cross-check the same on online home PCs are being
>monitored.

A.a.m nym replies always have an outer symmetric encryption layer hiding
key parameters of the most inner asymmetric layer(s).

But sure, if a suspect under surveillance holds the private key belonging
to the public key of a nymserver account they won. Btw, to allow
encrypted replies that public key is even added to the header section of
each nym message (X-PGP-Key-Public:). So better run Omnimix from within
an encrypted container and pull the plug when some TLA kicks in your front
door.

>
>Remailer users also do not know any warrant canaries from their remailer/nym server
>operators who could possibly keep them updated.

That's why we have to use Tor circuits and remailer chains of adequate
lengths.