Question regarding security programming newsgroups

Hello,

Can anyone please recommend me of a good newsgroup for security
and cryptography programming.

Thanks :-)

Bobby

Re: Question regarding security programming newsgroups

Bobby wrote:
> Can anyone please recommend me of a good newsgroup for security
> and cryptography programming.

Perhaps you could just start a discussion here, please.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

Bobby wrote:
> Hello,
>
> Can anyone please recommend me of a good newsgroup for security

here

> and cryptography programming.

sci.crypt

Re: Question regarding security programming newsgroups

"Bobby" wrote in message
news:cu01229o92d6v5j48fajl8mon6sthoos0o@4ax.com...
> Hello,
>
> Can anyone please recommend me of a good newsgroup for security
> and cryptography programming.
>
> Thanks :-)
>
> Bobby


alt.sources.crypto

--
Best regards, from Don Kelloway of Commodon Communications
Visit http://www.commodon.com to learn about the "Threats to Your Security
on the Internet".

Re: Question regarding security programming newsgroups

On 22 Mar 2006 00:02:53 +0100, Volker Birk wrote:

>Bobby wrote:
>> Can anyone please recommend me of a good newsgroup for security
>> and cryptography programming.
>
>Perhaps you could just start a discussion here, please.
>
>Yours,
>VB.

OK, thank you for the information.

Here is my story :

I am working on my project for the university - I plan on writing a
library which will replace the standard
socket api (tcp - socket, bind, listen, accept, connect, send, recv,
close, udp - sendto, recvfrom) and will
be a 'secure' socket layer.

for example - my send (SEND) will get the same arguments as 'send' but
before actually sending the buffer,
it will encrypt it, and RECV will first recv the buffer and then
decrypt it.

The key negotiation is quite easy in tcp - I put the code under
CONNECT and ACCEPT - CONNECT will trigger
a key exchnage on the client and ACCEPT will do the same on the server
(or remote peer).

I plan on using DH or RSA for the key negotiation - like in IPSec (not
like with certificate as in SSL)

I intend to write a simple database which will hold the keys and do a
quick lookup when they are needed
(in SEND and RECV).

My problem is with UDP.

When working in udp you just send a buffer or receive it without first
connecting/accepting, so I have to
put the code which does the key exchnage in/under the SENDTO /
RECVFROM functions.

for example : I can first check in SENDTO (before actually calling
'sendto') if I have keys for the ip address
to which I would like to send the packet, if I have the keys, I
encrypt and send the packet, if not I initiate a
key exchnage to the remote peer and after it completes, I can call
'sendto' - this way only the first packet
will be delayed, after the first one, I will have the keys in memory
and will be able to quikly look them up
and use them.

The problem here is that if A sends a packet to B and B sends a packet
to A (and they do it in a very short
timeframe), A will initiate a key exchnage to B and B will initiate a
key exchnage to A.

Can anybody help me out here ????

Thanks :-)

Bobby

Re: Question regarding security programming newsgroups

Bobby wrote:
> The problem here is that if A sends a packet to B and B sends a packet
> to A (and they do it in a very short
> timeframe), A will initiate a key exchnage to B and B will initiate a
> key exchnage to A.

Such a collision both could detect. Both of them should abandon one of
the opening connections - and both the same. Perhaps, just abandon the
connection, which was initiated by the smaller IP address (read as an
32bit integer in network byte order).

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 22 Mar 2006 22:06:08 +0100, Volker Birk wrote:

>Bobby wrote:
>> The problem here is that if A sends a packet to B and B sends a packet
>> to A (and they do it in a very short
>> timeframe), A will initiate a key exchnage to B and B will initiate a
>> key exchnage to A.
>
>Such a collision both could detect. Both of them should abandon one of
>the opening connections - and both the same. Perhaps, just abandon the
>connection, which was initiated by the smaller IP address (read as an
>32bit integer in network byte order).
>
>Yours,
>VB.

Yes, I thought of this idea also -
an IP address is usually an unsigned long, so you can set rules
for both sides (peers) such as only the smaller IP address is the one
which will initiate a key exchnage.
But, if I do that , for example I have peers A & B (A's ip < B's ip),
A would like to talk to B (A calls sentdo), then A initiates a key
exchnage, but if B is the initiator, then B has to send A some kind of
message which will trigger a key exchange on A - this causes B to
delay the packet - lets assume that B has a dedicated task which
only receives messages and calls 'sentdo' - like a transmit handler,
if I do the above I delay the whole transmit handler task (I also have
to find some way to let that task know that the key exchnage with
A was finished and that it can continue sending the packet.

I can also store the packet somewhere when the above scenario occurs,
(hold the packet) and then when the key exchnage finishes transmit the
packet.

Maybe there is an easier way to do the whole thing ?

Re: Question regarding security programming newsgroups

Bobby wrote:
> >> The problem here is that if A sends a packet to B and B sends a packet
> >> to A (and they do it in a very short
> >> timeframe), A will initiate a key exchnage to B and B will initiate a
> >> key exchnage to A.
> >Such a collision both could detect. Both of them should abandon one of
> >the opening connections - and both the same. Perhaps, just abandon the
> >connection, which was initiated by the smaller IP address (read as an
> >32bit integer in network byte order).
> But, if I do that , for example I have peers A & B (A's ip < B's ip),
> A would like to talk to B (A calls sentdo), then A initiates a key
> exchnage, but if B is the initiator, then B has to send A some kind of
> message which will trigger a key exchange on A - this causes B to
> delay the packet

When a connection A->B exists, then a second connection B->A should never
be accomplished, regardless of wether A>B or B>A.

When a connection A->B is in state connecting, and handshake packets for
a connection B->A arrive, then if B>A then A->B is dropped immediately,
else is A>B then B->A is dropped (if already in state connecting) and
the arriving packets must be ignored.

If both sides act like this, then as a result only one connection will
be there; a three way handshake for initiating connections is required,
though.

A packet is sent over connection A->B _or_ connection B->A using UDP.

> I can also store the packet somewhere when the above scenario occurs,
> (hold the packet) and then when the key exchnage finishes transmit the
> packet.

Of course you have to do so.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 23 Mar 2006 08:30:41 +0100, Volker Birk wrote:

>Bobby wrote:
>> >> The problem here is that if A sends a packet to B and B sends a packet
>> >> to A (and they do it in a very short
>> >> timeframe), A will initiate a key exchnage to B and B will initiate a
>> >> key exchnage to A.
>> >Such a collision both could detect. Both of them should abandon one of
>> >the opening connections - and both the same. Perhaps, just abandon the
>> >connection, which was initiated by the smaller IP address (read as an
>> >32bit integer in network byte order).
>> But, if I do that , for example I have peers A & B (A's ip < B's ip),
>> A would like to talk to B (A calls sentdo), then A initiates a key
>> exchnage, but if B is the initiator, then B has to send A some kind of
>> message which will trigger a key exchange on A - this causes B to
>> delay the packet
>
>When a connection A->B exists, then a second connection B->A should never
>be accomplished, regardless of wether A>B or B>A.

I assume you mean that A and B already had a key exchnage, then both
should have keys for this connection in their DB and should not need
to negotiate (maybe re-negotiate to re-key)

>
>When a connection A->B is in state connecting, and handshake packets for
>a connection B->A arrive, then if B>A then A->B is dropped immediately,
>else is A>B then B->A is dropped (if already in state connecting) and
>the arriving packets must be ignored.

If you set rules - such as the smaller ip addr is always the initiator
of a key negotiation, you would not need to drop the negotiation,
since if A< B, and A and B have to negotiate keys, only A will
initiate a key exchnage .
If A he should send some kind of notification to A, so A will initiate a
key exchnage.
>
>If both sides act like this, then as a result only one connection will
>be there; a three way handshake for initiating connections is required,
>though.
>
>A packet is sent over connection A->B _or_ connection B->A using UDP.
>

I didn't understand this part - could you please explain a little
furthe
r
>> I can also store the packet somewhere when the above scenario occurs,
>> (hold the packet) and then when the key exchnage finishes transmit the
>> packet.
>
>Of course you have to do so.

The problem is that I do not want to do so, I want to focus on the
security functions and not on another 'sub' project I have to do if
I would like to write a mechanism which will cycle through a list
of packets, each entry will hold a packet that is "waiting" for the
key exchnage to end - then the entry will be marked with a flag,
and the next time the task which is responsibe for sending marked
packets will arrive to this entry, it will send the packet.

There must be some other way to do the whole thing without buffering
the packet (and without delaying the transmiting application)
>
>Yours,
>VB.

Re: Question regarding security programming newsgroups

Bobby wrote:
> >When a connection A->B is in state connecting, and handshake packets for
> >a connection B->A arrive, then if B>A then A->B is dropped immediately,
> >else is A>B then B->A is dropped (if already in state connecting) and
> >the arriving packets must be ignored.
> If you set rules - such as the smaller ip addr is always the initiator
> of a key negotiation, you would not need to drop the negotiation,
> since if A< B, and A and B have to negotiate keys, only A will
> initiate a key exchnage .
> If A > he should send some kind of notification to A, so A will initiate a
> key exchnage.

This will not work, because maybe B wants to send an UDP frame to A, but
A does not want to, so B initiates even if B here should work anyways.

> >If both sides act like this, then as a result only one connection will
> >be there; a three way handshake for initiating connections is required,
> >though.
> >A packet is sent over connection A->B _or_ connection B->A using UDP.
> I didn't understand this part - could you please explain a little
> further

A wants to send to B:
do
if there is A->B already, then
use A->B
else if there is B->A already, then
use B->A
else
connect
while not using connection yet

Hm... it's easier to write the C code ;-)

"connect" from A->B _can_ have A->B as a result; it can have B->A, too,
if there was a second connection vice versa at the same time, and B>A.

> >> I can also store the packet somewhere when the above scenario occurs,
> >> (hold the packet) and then when the key exchnage finishes transmit the
> >Of course you have to do so.
> The problem is that I do not want to do so

I see no other choice with UDP. UDP is connectionless, so you have to
implement connections.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 23 Mar 2006 21:54:39 +0100, Volker Birk wrote:

>Bobby wrote:
>> >When a connection A->B is in state connecting, and handshake packets for
>> >a connection B->A arrive, then if B>A then A->B is dropped immediately,
>> >else is A>B then B->A is dropped (if already in state connecting) and
>> >the arriving packets must be ignored.
>> If you set rules - such as the smaller ip addr is always the initiator
>> of a key negotiation, you would not need to drop the negotiation,
>> since if A< B, and A and B have to negotiate keys, only A will
>> initiate a key exchnage .
>> If A >> he should send some kind of notification to A, so A will initiate a
>> key exchnage.
>
>This will not work, because maybe B wants to send an UDP frame to A, but
>A does not want to, so B initiates even if B >here should work anyways.
>
>> >If both sides act like this, then as a result only one connection will
>> >be there; a three way handshake for initiating connections is required,
>> >though.
>> >A packet is sent over connection A->B _or_ connection B->A using UDP.
>> I didn't understand this part - could you please explain a little
>> further
>
>A wants to send to B:
> do
> if there is A->B already, then
> use A->B
> else if there is B->A already, then
> use B->A
> else
> connect
> while not using connection yet
>
>Hm... it's easier to write the C code ;-)
>
>"connect" from A->B _can_ have A->B as a result; it can have B->A, too,
>if there was a second connection vice versa at the same time, and B>A.
>
>> >> I can also store the packet somewhere when the above scenario occurs,
>> >> (hold the packet) and then when the key exchnage finishes transmit the
>> >Of course you have to do so.
>> The problem is that I do not want to do so
>
>I see no other choice with UDP. UDP is connectionless, so you have to
>implement connections.
>
>Yours,
>VB.

Hi Again and many thnaks for your help :-)

I might be a little dumb because I still don't quite understand your
explanation, so I will write a few facts and you can verify them or
not

fact 1 - the peer with the smaller ip always initiates the key
exchnage

fact 2 - if a peer wants to send a packet, it checks if it has keys
with the other peer, if yes, its just sends the packet.

fact 3 - if the peer doesn't have keys , it will check if its ip is
smaller the the second peer's ip.

fact 4 - if its ip is smaller, it will initiates a key exchnage

fact 5 - if its ip is bigger, it will hold the packet by some
mechanism and send a notification to the second peer
asking it to initiate a key exchange to him

fact 6 - if the peer with the smaller ip gets such a notification,
it will initiate a key exchnage (unless it is already in the middle
of such a key exchnage with the other peer).

If I summerize all the possible options :
-----------------------------------------------------------

there are two peers - A & B, A < B

option 1 -
------------

A & B don't have keys at all for each other.

if A sends a packet to B, it will insert the packet into
the hold mechanism and initiate a key exchnage to B.

if B sends a packet it will insert the packet into
the hold mechanism and send A a notification asking
A to initiate a key exchnage

option 2 -
-------------

A has a key, B doesn't (it once had but it was rebooted)

A has a key so it encrypt the packet and sends it to B
B gets the packet but since it doesn't have keys with A
it throws away the packet, it send A a notification asking
A to initiate a key exchnage

B sends a packet to A - it doesn't have keys, so it will insert
the packet into the hold mechanism and send A a notification
asking A to initiate a key exchnage.

option 3 -
-------------

A doesn't have a key, B has a key

A sends a packet to B, since it doesn't have a key, it
will insert the packet into the hold mechanism and
initiate a key exchnage to B

B sends a packet ot A - it will use the keys which A
doesn't have, A will know that he doesn't have keys with B
and will drop the packet, it will also initiate a key exchnage to B

In these scenarios, if one side doesn't have a key, and the other
side who does have a key sends a packet, it will get lost.

As for the hold mechanism, I would think of an array of some sort
of struct which will hold the ip addr of the peer who should receive
that packet - so the task which will cycle over this table will just
try to lookup the ip addr in the keys db, if it finds the key, then
the key exchnage was finished and both sides probably have the same
keys, so it can encrypt & send the packet.
If it doesn't find the ip addr in the keys db, it will ignore this
entry and move on to the next.

What is the difference between your idea and this one ?

Thanks :-)

Bobby

Re: Question regarding security programming newsgroups

Bobby wrote:
> fact 1 - the peer with the smaller ip always initiates the key
> exchnage

No. Both peers may initiate. This is required, because perhaps the peer
with the larger IP has need to initiate, while the one with the smaller
IP does not know this need yet.

> fact 2 - if a peer wants to send a packet, it checks if it has keys
> with the other peer, if yes, its just sends the packet.

Yes.

> fact 3 - if the peer doesn't have keys , it will check if its ip is
> smaller the the second peer's ip.

No. It will initiate key exchange, creating a connection.

> fact 4 - if its ip is smaller, it will initiates a key exchnage
> fact 5 - if its ip is bigger, it will hold the packet by some
> mechanism and send a notification to the second peer
> asking it to initiate a key exchange to him

This would be possible, too. But it is not what I described ;-)

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 24 Mar 2006 00:12:31 +0100, Volker Birk wrote:

>Bobby wrote:
>> fact 1 - the peer with the smaller ip always initiates the key
>> exchnage
>
>No. Both peers may initiate. This is required, because perhaps the peer
>with the larger IP has need to initiate, while the one with the smaller
>IP does not know this need yet.
>

OK, I think I got it - that is why you wrote that the key exchnage
requires a 3 way handshake - only a fter a good handshake it
will begin.

BUT, there is always the problem that A and B don't have keys, and
both want to send packets to each other at the same time, so A
initiates a key exchnage and so does B, so now B gets a request from
A to start negotiating after it sent the same thing to A and vice
versa - they have to decide who will continue and who will not
continue - so you still need some kind of rule to help you decide -
maybe both create a random number and send it to the other side,
whoever has the larger number "wins"

>> fact 2 - if a peer wants to send a packet, it checks if it has keys
>> with the other peer, if yes, its just sends the packet.
>
>Yes.
>
>> fact 3 - if the peer doesn't have keys , it will check if its ip is
>> smaller the the second peer's ip.
>
>No. It will initiate key exchange, creating a connection.
>
>> fact 4 - if its ip is smaller, it will initiates a key exchnage
>> fact 5 - if its ip is bigger, it will hold the packet by some
>> mechanism and send a notification to the second peer
>> asking it to initiate a key exchange to him
>
>This would be possible, too. But it is not what I described ;-)
>
>Yours,
>VB.

Regarding your pseudo code :

A wants to send to B:
do
if there is A->B already, then
use A->B
else if there is B->A already, then
use B->A
else
connect
while not using connection yet

when you write A->B - do you mean that A has keys with B?
what do you exactly mean by 'while not using connection yet' ?

Thanks :-)

Bobby

Re: Question regarding security programming newsgroups

Bobby wrote:
> BUT, there is always the problem that A and B don't have keys, and
> both want to send packets to each other at the same time, so A
> initiates a key exchnage and so does B, so now B gets a request from
> A to start negotiating after it sent the same thing to A and vice
> versa - they have to decide who will continue and who will not
> continue - so you still need some kind of rule to help you decide -
> maybe both create a random number and send it to the other side,
> whoever has the larger number "wins"

Why not using the IP address for this - as I suggested?

> Regarding your pseudo code :
> A wants to send to B:
> do
> if there is A->B already, then
> use A->B
> else if there is B->A already, then
> use B->A
> else
> connect
> while not using connection yet
> when you write A->B - do you mean that A has keys with B?

I mean, A has keys with B, because A initiated key exchange for a
connection to B. With B->A I mean, that A has keys with B, because
B initiated a connection with A.

> what do you exactly mean by 'while not using connection yet' ?

I see the states not connected, in connection, connected for a connection.
For a transmission I see waiting for connection, using connection.

BTW: nice idea! One should hack this and supply as a patch to an existing
kernel, like the Linux kernel or some BSD kernel.

If help is appreciated, I'd like to join in.

It could be a good idea to do it for IP. And there are some problems with
possibilities for DoS attacks I can see already.

When we're doing it for IP, then there is no need any more to determine
between UDP and TCP or other protocols. It's like an autoconfig IPSec then.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 24 Mar 2006 09:22:29 +0100, Volker Birk wrote:

>Bobby wrote:
>> BUT, there is always the problem that A and B don't have keys, and
>> both want to send packets to each other at the same time, so A
>> initiates a key exchnage and so does B, so now B gets a request from
>> A to start negotiating after it sent the same thing to A and vice
>> versa - they have to decide who will continue and who will not
>> continue - so you still need some kind of rule to help you decide -
>> maybe both create a random number and send it to the other side,
>> whoever has the larger number "wins"
>
>Why not using the IP address for this - as I suggested?

OK, so both sides will be able to initiate a key exchnage,
A initiates to B and B to A.
A will get B's packet and since it is already in a key exchnage with B
check if A < B, if yes , it will continue with the key exchnage, else
it will stop the key exchnage.
The same goes for B - that is what you mean , right ?


>> Regarding your pseudo code :
>> A wants to send to B:
>> do
>> if there is A->B already, then
>> use A->B
>> else if there is B->A already, then
>> use B->A
>> else
>> connect
>> while not using connection yet
>> when you write A->B - do you mean that A has keys with B?
>
>I mean, A has keys with B, because A initiated key exchange for a
>connection to B. With B->A I mean, that A has keys with B, because
>B initiated a connection with A.

Why do you have to ask about both cases - lets say A has to ask such a
thing, it actually does a quick lookup in its key db - looking up if
it has keys for B - if it does (and it doesn't matter if the keys were
because of a key negotiation initiated by A or by B), it uses the keys
to encrypt the packet and send it to B

>> what do you exactly mean by 'while not using connection yet' ?
>
>I see the states not connected, in connection, connected for a connection.
>For a transmission I see waiting for connection, using connection.

sorry, but I still do not understand exactly what you mean here

>BTW: nice idea! One should hack this and supply as a patch to an existing
>kernel, like the Linux kernel or some BSD kernel.

which idea is a nice idea (and by the way - you earned the credit
becuase you suggested using the ip as a way to set a rule for the
key exchnage

>If help is appreciated, I'd like to join in.
>
>It could be a good idea to do it for IP. And there are some problems with
>possibilities for DoS attacks I can see already.

What do you mean by 'it' (It could be a good idea to do it for IP) ?

>When we're doing it for IP, then there is no need any more to determine
>between UDP and TCP or other protocols. It's like an autoconfig IPSec then.

Again, I don't understand what do you mean by 'it' - please excuse me,
I am a slow learner, but after a while, I figure things out.

>Yours,
>VB.

Thanks :-)

Bobby

Re: Question regarding security programming newsgroups

Bobby wrote:
> OK, so both sides will be able to initiate a key exchnage,
> A initiates to B and B to A.
> A will get B's packet and since it is already in a key exchnage with B
> check if A < B, if yes , it will continue with the key exchnage, else
> it will stop the key exchnage.
> The same goes for B - that is what you mean , right ?

Yes.

> >> Regarding your pseudo code :
> >> A wants to send to B:
> >> do
> >> if there is A->B already, then
> >> use A->B
> >> else if there is B->A already, then
> >> use B->A
> >> else
> >> connect
> >> while not using connection yet
> >> when you write A->B - do you mean that A has keys with B?
> >
> >I mean, A has keys with B, because A initiated key exchange for a
> >connection to B. With B->A I mean, that A has keys with B, because
> >B initiated a connection with A.
> Why do you have to ask about both cases - lets say A has to ask such a
> thing, it actually does a quick lookup in its key db - looking up if
> it has keys for B - if it does (and it doesn't matter if the keys were
> because of a key negotiation initiated by A or by B), it uses the keys
> to encrypt the packet and send it to B

Yes, this is a way it can be implemented. I'm just thinking in connections,
but of course, you can implement it this way.

> >> what do you exactly mean by 'while not using connection yet' ?
> >I see the states not connected, in connection, connected for a connection.
> >For a transmission I see waiting for connection, using connection.
> sorry, but I still do not understand exactly what you mean here

For the protocol, I see states. For a transmission, I see states.
Of course, "in connection" means more states, the ones for the key
exchange (three way handshake).

> >BTW: nice idea! One should hack this and supply as a patch to an existing
> >kernel, like the Linux kernel or some BSD kernel.
> which idea is a nice idea

A nice idea is to handle this transparently to the programmer _and_
transparently to the admininstrator.

> >If help is appreciated, I'd like to join in.
> >It could be a good idea to do it for IP. And there are some problems with
> >possibilities for DoS attacks I can see already.
> What do you mean by 'it' (It could be a good idea to do it for IP) ?

Yes. Sorry for my bad English ;-)

> >When we're doing it for IP, then there is no need any more to determine
> >between UDP and TCP or other protocols. It's like an autoconfig IPSec then.
> Again, I don't understand what do you mean by 'it' - please excuse me,
> I am a slow learner, but after a while, I figure things out.

If you're implementing this for IP and not for UDP or TCP, then it's like
an autoconfig IPSec.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 24 Mar 2006 13:29:05 +0100, Volker Birk wrote:

>Bobby wrote:
>> OK, so both sides will be able to initiate a key exchnage,
>> A initiates to B and B to A.
>> A will get B's packet and since it is already in a key exchnage with B
>> check if A < B, if yes , it will continue with the key exchnage, else
>> it will stop the key exchnage.
>> The same goes for B - that is what you mean , right ?
>
>Yes.
>
>> >> Regarding your pseudo code :
>> >> A wants to send to B:
>> >> do
>> >> if there is A->B already, then
>> >> use A->B
>> >> else if there is B->A already, then
>> >> use B->A
>> >> else
>> >> connect
>> >> while not using connection yet
>> >> when you write A->B - do you mean that A has keys with B?
>> >
>> >I mean, A has keys with B, because A initiated key exchange for a
>> >connection to B. With B->A I mean, that A has keys with B, because
>> >B initiated a connection with A.
>> Why do you have to ask about both cases - lets say A has to ask such a
>> thing, it actually does a quick lookup in its key db - looking up if
>> it has keys for B - if it does (and it doesn't matter if the keys were
>> because of a key negotiation initiated by A or by B), it uses the keys
>> to encrypt the packet and send it to B
>
>Yes, this is a way it can be implemented. I'm just thinking in connections,
>but of course, you can implement it this way.
>
>> >> what do you exactly mean by 'while not using connection yet' ?
>> >I see the states not connected, in connection, connected for a connection.
>> >For a transmission I see waiting for connection, using connection.
>> sorry, but I still do not understand exactly what you mean here
>
>For the protocol, I see states. For a transmission, I see states.
>Of course, "in connection" means more states, the ones for the key
>exchange (three way handshake).
>
>> >BTW: nice idea! One should hack this and supply as a patch to an existing
>> >kernel, like the Linux kernel or some BSD kernel.
>> which idea is a nice idea
>
>A nice idea is to handle this transparently to the programmer _and_
>transparently to the admininstrator.

OK, so I assume you mean the idea of replacing all the calls to the
socket api (send/recv/connect/accept etc.) with calls to a secure
socket API, right ?

>> >If help is appreciated, I'd like to join in.
>> >It could be a good idea to do it for IP. And there are some problems with
>> >possibilities for DoS attacks I can see already.
>> What do you mean by 'it' (It could be a good idea to do it for IP) ?
>
>Yes. Sorry for my bad English ;-)
>
>> >When we're doing it for IP, then there is no need any more to determine
>> >between UDP and TCP or other protocols. It's like an autoconfig IPSec then.
>> Again, I don't understand what do you mean by 'it' - please excuse me,
>> I am a slow learner, but after a while, I figure things out.
>
>If you're implementing this for IP and not for UDP or TCP, then it's like
>an autoconfig IPSec.

Forgive my question, but How can you implement this idea for IP ?
When working with the sockets api I mentioned earlier, you use api
for stream socket (TCP) or datagram sockets (UDP), maybe I don't have
enough experience with network programming (probably), so please
explain this a little more

Thanks :-)

Bobby

>Yours,
>VB.

Re: Question regarding security programming newsgroups

Bobby wrote:
> >A nice idea is to handle this transparently to the programmer _and_
> >transparently to the admininstrator.
> OK, so I assume you mean the idea of replacing all the calls to the
> socket api (send/recv/connect/accept etc.) with calls to a secure
> socket API, right ?

Yes.

> >If you're implementing this for IP and not for UDP or TCP, then it's like
> >an autoconfig IPSec.
> Forgive my question, but How can you implement this idea for IP ?

Implementing it as virtual network driver.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 25 Mar 2006 08:14:28 +0100, Volker Birk wrote:

>Bobby wrote:
>> >A nice idea is to handle this transparently to the programmer _and_
>> >transparently to the admininstrator.
>> OK, so I assume you mean the idea of replacing all the calls to the
>> socket api (send/recv/connect/accept etc.) with calls to a secure
>> socket API, right ?
>
>Yes.
>
>> >If you're implementing this for IP and not for UDP or TCP, then it's like
>> >an autoconfig IPSec.
>> Forgive my question, but How can you implement this idea for IP ?
>
>Implementing it as virtual network driver.

Interesting - this can be done for both windows & Linux ?
If yes, do you have any good link that can teach me how to do this?

Thanks :-)

Bobby

Re: Question regarding security programming newsgroups

Bobby wrote:
> >Implementing it as virtual network driver.
> Interesting - this can be done for both windows & Linux ?

Yes. And for many other OSes, too.

> If yes, do you have any good link that can teach me how to do this?

www.google.c^WAhem... Please use a searching machine ;-) And, my offer
persists: if you want to, I'd like to join in. Let's start a Free Software
project for it.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 25 Mar 2006 11:35:48 +0100, Volker Birk wrote:

>Bobby wrote:
>> >Implementing it as virtual network driver.
>> Interesting - this can be done for both windows & Linux ?
>
>Yes. And for many other OSes, too.

Do you know which other OS's ?

>> If yes, do you have any good link that can teach me how to do this?
>
>www.google.c^WAhem... Please use a searching machine ;-) And, my offer
>persists: if you want to, I'd like to join in. Let's start a Free Software
>project for it.

OK, never done that before - how can you share work over the internet
?

Regards :-)

bobby

Re: Question regarding security programming newsgroups

Bobby wrote:
> On 25 Mar 2006 11:35:48 +0100, Volker Birk wrote:
> >Bobby wrote:
> >> >Implementing it as virtual network driver.
> >> Interesting - this can be done for both windows & Linux ?
> >Yes. And for many other OSes, too.
> Do you know which other OS's ?

Nearly for every OS. At least for FreeBSD, OpenBSD, NetBSD and any
System V UNIX, like HP-UX or Solaris.

> >Let's start a Free Software
> >project for it.
> OK, never done that before - how can you share work over the internet?

Let's use http://savannah.gnu.org/ - we could have an LGPL license for this.

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Re: Question regarding security programming newsgroups

On 25 Mar 2006 21:43:23 +0100, Volker Birk wrote:

>Bobby wrote:
>> On 25 Mar 2006 11:35:48 +0100, Volker Birk wrote:
>> >Bobby wrote:
>> >> >Implementing it as virtual network driver.
>> >> Interesting - this can be done for both windows & Linux ?
>> >Yes. And for many other OSes, too.
>> Do you know which other OS's ?
>
>Nearly for every OS. At least for FreeBSD, OpenBSD, NetBSD and any
>System V UNIX, like HP-UX or Solaris.
>
>> >Let's start a Free Software
>> >project for it.
>> OK, never done that before - how can you share work over the internet?
>
>Let's use http://savannah.gnu.org/ - we could have an LGPL license for this.
>
>Yours,
>VB.

Hi VB

sorry for the late reply,
I'm was/am sicj in the last couple of days.
I will check the site you mentioned.
BTW - I leave for the US next week for a
month, so we will start after I get back,
please send me your personal email so I can
get back to you

Thanks :-)