public inbox for nncp-devel@lists.stargrave.org
Atom feed
* Question about areas
@ 2025-09-24 17:55 Hadmut Danisch
2025-09-25 15:16 ` Sergey Matveev
0 siblings, 1 reply; 2+ messages in thread
From: Hadmut Danisch @ 2025-09-24 17:55 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]
Hi,
a question about areas:
I recently tried to use areas (nncp 8.10.0, Ubuntu 24.04), and wanted to
build something like
A
/ \
B C
/ \ / \
D E F G
where A (sender only) sends messages to an area with members B and C
(without knowing about D,E,F,G), and B and C just forward (without
reading the message) to D,E , F, G, where B knows about members D and
E, and C knows about F and G.
A is sender only, B,C are keyless forwarders only, and D,E,F,G are
receivers only and final recipients, thus need to have the secret keys.
Only A is origin of messages.
I had expected that I have to give A only the public key of the area key
set. But I got an error message, that A requires the secret key of the
area as well. In constrast, the docs at
http://www.nncpgo.org/Multicast.html tell, that B and C as pure
fordwarders would not need to have any keys at all to just forward.
So my concern is: What does A need the secret key of the are for? Isn't
that a security flaw, if A stores encrypted message until transport, but
the keys as well? If I understand this correctly, when sending a message
to an area on A, the message is first encrypted for the area (where it
needs the public key for), but then immediately descrypted again by
nncp-toss to redistribute.
But: What does A need to decrypt the message for, if forwarders B and C
(or, in the example on http://www.nncpgo.org/Multicast.html, node B)
don't need any keys at all just to forward a message to known members of
the area. Why is sending and forwarding implemented differently?
I my eyes, it should be sufficient for node A to just have the public
keys of the area to encrypt the message, and then forward it to members
just like a keyless forwarder.
I do consider it as insecure, if node A, which is solely a sender to the
area and not a member, needs to have the secret keys. E.g. on an email
relay in a cloud, an attacker who get's access to the machine, can
immediately decrypt all messages in the spool directory.
So my question is: Why does A require posession of the secret keys? What
does it need them for, if forwarding is possible without keys?
Best regards
Hadmut
[-- Attachment #2: Type: text/html, Size: 3170 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: Question about areas
2025-09-24 17:55 Question about areas Hadmut Danisch
@ 2025-09-25 15:16 ` Sergey Matveev
0 siblings, 0 replies; 2+ messages in thread
From: Sergey Matveev @ 2025-09-25 15:16 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]
Greetings!
*** Hadmut Danisch [2025-09-24 19:55]:
>So my question is: Why does A require posession of the secret keys? What
>does it need them for, if forwarding is possible without keys?
"A" must not require it, you are right. I really do not remember why
that check was left in Tx() function. Seems that it was initially added
and forgotten to be removed.
Thanks for noticing that!
I hope I will find time to make a release on that weekend and try to
make an updated port for FreeBSD, where net/nncp is pretty outdated. But
that patch (pushed to "develop" branch) will stop requiring you to have
area's private key for sending:
diff --git src/tx.go src/tx.go
index e0f4f08..2504135 100644
--- src/tx.go
+++ src/tx.go
@@ -59,9 +59,6 @@ func (ctx *Ctx) Tx(
var area *Area
if areaId != nil {
area = ctx.AreaId2Area[*areaId]
- if area.Prv == nil {
- return nil, 0, "", errors.New("area has no encryption keys")
- }
}
hops := make([]*Node, 0, 1+len(node.Via))
hops = append(hops, node)
>I do consider it as insecure, if node A, which is solely a sender to the
>area and not a member, needs to have the secret keys. E.g. on an email relay
>in a cloud, an attacker who get's access to the machine, can immediately
>decrypt all messages in the spool directory.
I would not consider any cloud computer as safe at all. It is not under
your control, so if one creates any packets, then any cloud provider can
see the generated/passed plaintext, that definitely existed in
pipes/memory/tmpfiles before the encryption.
--
Sergey Matveev (http://www.stargrave.org/)
LibrePGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-09-25 15:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-09-24 17:55 Question about areas Hadmut Danisch
2025-09-25 15:16 ` Sergey Matveev