I want to try to implement some form of concealed port knocking in
OpenBSD, along the lines of Martin Kirsch:
https://gnunet.org/sites/default/files/ma_kirsch_2014_0.pdf
The application is electronic democracy. I want to demonstrate how it
is possible to do secure comms. over untrusted networ
On Sat, Oct 11, 2014 at 5:45 AM, Joachim Schipper
wrote:
> somewhat interesting>
Moved back to tech for just this message:
I am going to implement this inBSD, so I would still appreciate
pointers and helpful tech advice, but please don't CC the list, just
mail me privately.
To prevent a flame
On Fri, Oct 10, 2014 at 7:31 PM, Ian Grant wrote:
> I want to try to implement some form of concealed port knocking in
> OpenBSD, along the lines of [Julian] Kirsch:
Thanks to everyone that replied. You know who you aren't :-)
Several people said I should look at adding (to pf) a ne
On a related note, I want to implement services on bochs VM's and pass
them from one physical host machine to another, so that the physical
addresses are not fixed targets. I am a bit confused about the bochs
host implementation of networking. What bochs hardware works best on
OpenBSD? Has anyone m
On Fri, Oct 17, 2014 at 12:58 PM, Ian Grant
wrote:
> On a related note, I want to implement services on bochs VM's and pass
> them from one physical host machine to another, so that the physical
> addresses are not fixed targets.
qemu looks a bit better than bochs.
I am wonderin
On Fri, Oct 17, 2014 at 5:56 PM, Ian Grant wrote:
> The whole thing also needs to be runnable over "USB stick net" in extremis.
And mobile WiFi as per "What they should be doing" on:
http://livelogic.blogspot.com/
On Mon, Oct 20, 2014 at 8:10 PM, Theo de Raadt wrote:
> You are off-topic for this mailing list. Please go discuss it
> elsewhere.
Theo,
Does this include my questions on tech? I still want to do this, even
of a hundred little pricks don't understand what it is.
I think I can make a very tidy
This refers to the un-patched OpenBSD 5.5 source tree.
Whilst trying to understand the notion of "direction" of packet flow
in pf(4) I came across this potential problem:
In pf.conf(5) we have:
When forwarding reassembled IPv6 packets, pf refragments them with
the original maximum fragment
> And when you have more than words, please put it on a a
> web site and do nothing more than tell people once.
Still a lot of words, but code too, and an outline of a test framework
that others may be interested in using. I would be happy to take into
account any other ideas people might have abo
I beg your collective pardons. I didn't notice the netinet6 directory!
Old timer ...
Ian
On Sat, Oct 25, 2014 at 1:02 PM, Henning Brauer
wrote:
> * Ian Grant [2014-10-25 18:15]:
>> #ifdef INET6
>> /* if reassembled packet passed, create new fragments */
>&g
10 matches
Mail list logo
