public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* segfault with areas
@ 2021-08-07 21:12 John Goerzen
2021-08-07 21:41 ` Sergey Matveev
2021-08-08 8:52 ` Areas authorization Sergey Matveev
0 siblings, 2 replies; 4+ messages in thread
From: John Goerzen @ 2021-08-07 21:12 UTC (permalink / raw)
To: nncp-devel
Hi Sergey,
I am wanting to set up an area where only one node is authorized
to create packets bound for it, but a bunch of nodes can receive
those packets. I thought I might do so by distributing the prv
line of the area to every node, but keeping the pub line to only
the node authorized to send. It is a bit counter-intuitive to how
one normally shares the keys, but in this case what I'm trying to
do is set up an automatic distribution of the nodelist and I want
it to occur from onlyh a trusted source, and the file itself isn't
particularly sensitive.
I believe this is working as intended and I would like the
behavior to remain.
In testing, I thought "what would happen if I try to nncp-exec
area:nodelist newnodelist on a box that doesn't have the pub line
for the area?" I expected an error. Got a segfault instead:
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0
pc=0x5ca1cb]
goroutine 11 [running]:
go.cypherpunks.ru/nncp/v7.(*Ctx).Tx.func2(0xc000116f00,
0xc00001d200, 0x60, 0xc000019420, 0xc000166240, 0xc00001a1e0,
0xc00001a180, 0x12, 0x0, 0x65c8a0, ...)
/home/nncp/nncp-7.5.0/src/tx.go:139 +0x2cb
created by go.cypherpunks.ru/nncp/v7.(*Ctx).Tx
/home/nncp/nncp-7.5.0/src/tx.go:124 +0x538
This is on v7.5.0.
I think the overall behavior is correct - it should be able to
receive but not send if it has only prv, to send but not receive
if it has only pub, both if it has both, and neither if it has
neither - but probably the segfault wasn't what was intended.
Thanks!
- John
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: segfault with areas
2021-08-07 21:12 segfault with areas John Goerzen
@ 2021-08-07 21:41 ` Sergey Matveev
2021-08-08 3:10 ` John Goerzen
2021-08-08 8:52 ` Areas authorization Sergey Matveev
1 sibling, 1 reply; 4+ messages in thread
From: Sergey Matveev @ 2021-08-07 21:41 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2229 bytes --]
Greetings!
*** John Goerzen [2021-08-07 16:12]:
>I am wanting to set up an area where only one node is authorized to create
>packets bound for it, but a bunch of nodes can receive those packets. I
>thought I might do so by distributing the prv line of the area to every
>node, but keeping the pub line to only the node authorized to send.
If you know private key -- you always can deterministically generate
public key from it. *25519, *448, ECDSA and similar algorithms are
mathematically constructed that way. Public key can be completely
ignored in the storage and computed from private key all the time --
this is just more CPU hungry.
Current areas architecture has no ability to make any kind of sender's
authorization. You can only check the signature of the sender and
determine is it authorized one or not. Everything that NNCP can do is
check against predefined "trusted"/authorized senders in the
configuration file (currently there is no that option, but can be
relatively easily added).
>In testing, I thought "what would happen if I try to nncp-exec area:nodelist
>newnodelist on a box that doesn't have the pub line for the area?"
I will add an additional check that either both prv/pub exists, or none
of them. I did not expect someone will leave only "prv" field :-)
>I think the overall behavior is correct - it should be able to receive but
>not send if it has only prv
"Sending" capability can be *artificially* limited, but private key
knowledge (that is required for reception) automatically gives you
public key knowledge too, from mathematical point of view. If anyone
wants to pass that artificial restriction, it would be trivial, just
changing the couple of source code lines and recompiling. So that is not
possible. NNCP's areas are very simple multicast capability and nothing
more: no moderation, no authorization, no roles (moderator,
administrator, poster, owner, whatever). Only signed encrypted packets,
copied to multiple recipients on each hop.
>segfault wasn't what was intended.
Segfaults are never intended to be of course.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: segfault with areas
2021-08-07 21:41 ` Sergey Matveev
@ 2021-08-08 3:10 ` John Goerzen
0 siblings, 0 replies; 4+ messages in thread
From: John Goerzen @ 2021-08-08 3:10 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Sat, Aug 07 2021, Sergey Matveev wrote:
> *** John Goerzen [2021-08-07 16:12]:
>>I am wanting to set up an area where only one node is authorized
>>to create
>>packets bound for it, but a bunch of nodes can receive those
>>packets. I
>>thought I might do so by distributing the prv line of the area
>>to every
>>node, but keeping the pub line to only the node authorized to
>>send.
>
> If you know private key -- you always can deterministically
> generate
> public key from it. *25519, *448, ECDSA and similar algorithms
> are
Ah, today I learned. Thank you. Well I'll solve that one another
way then.
I'm currently working on a set of scripts and things to automate
nodelist distribution, and hope to have a relay up and running at
SDF in a few days.
- John
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Areas authorization
2021-08-07 21:12 segfault with areas John Goerzen
2021-08-07 21:41 ` Sergey Matveev
@ 2021-08-08 8:52 ` Sergey Matveev
1 sibling, 0 replies; 4+ messages in thread
From: Sergey Matveev @ 2021-08-08 8:52 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]
*** John Goerzen [2021-08-07 16:12]:
>I am wanting to set up an area where only one node is authorized to create
>packets bound for it
There are some quick thoughts, just brainstorming, currently not taking
it seriously: what a node can do with incoming area packet? It has only
knowledge of area id, sender id, probably its signature verification.
* delete it
* relay it, then delete (no area's private key)
* relay and accept for local delivery, without signature check (unknown sender)
* relay and accept for local delivery, with verified signature
* relay and deny for local delivery (untrusted sender)
I thought that all logic can be moved to separate executable script
(shell, Perl, whatever user wish), that will be executed with (for
example, just brainstorming) three arguments: area id, sender id,
is signature valid. (I think that if sender is known, but has invalid
signature -- its packet can be dropped immediately). And that utility
will return the "decision". Something like:
#!/bin/sh
AREA=$1
SENDER=$2
[ "$SENDER" == `hash-of-nncp-neigh alice` ] && return CODE-TO-ACCEPT
[ "$SENDER" == `hash-of-nncp-neigh bob` ] && return CODE-TO-RELAY-ONLY
[ "$SENDER" == "unknown" ] && return return CODE-TO-DENY-COMPLETELY
But there are not so much actions possible, so I tend to think this is
unnecessary complication and just several lists can be kept inside
NNCP's configuration. "deny/allow-relay: [...]", "deny/allow-process:
[...]", and so on.
FidoNet did not have moderation as Internet's maillists, where you mail
was kept on maillist server until moderator decide what to do with it.
FidoNet's moderator warned and asked nodes to look for their points
behaviour. Noone can really completely forbid all messages spreading.
Usenet, as I understood, had the same issue: everyone can spread his
messages and if someone want to blind them, he just setup his own
personal "killfile". Moderated Usenet newsgroups has centralized point
of moderation, so it is not the floodfill multicasting.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-08-08 8:52 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-07 21:12 segfault with areas John Goerzen
2021-08-07 21:41 ` Sergey Matveev
2021-08-08 3:10 ` John Goerzen
2021-08-08 8:52 ` Areas authorization Sergey Matveev