I would love a copy of that as well.
Sampsa
On 27 Aug 2008, at 21:48, Fred wrote:
Hi all ...
I noticed MONK:: has some notes conferences available. I'd like to browse them, but my Alpha is missing a NOTES kit. I downloaded a kit from an associate of mine, but my two problems are:
1. his Alpha is shut down at the moment
2. I downloaded the Japanese kit from his Alpha by accident
Could someone zip up a (English) notes kit for me and send it? I can also FTP or do a copy over HECNET if you give me a node::disk:[dir] combo ... :)
Cheers,
Fred
Hi all ...
I noticed MONK:: has some notes conferences available. I'd like to browse them, but my Alpha is missing a NOTES kit. I downloaded a kit from an associate of mine, but my two problems are:
1. his Alpha is shut down at the moment
2. I downloaded the Japanese kit from his Alpha by accident
Could someone zip up a (English) notes kit for me and send it? I can also FTP or do a copy over HECNET if you give me a node::disk:[dir] combo ... :)
Cheers,
Fred
I am aware of the issues with both ECB (statistical inference, known plaintext attacks, replay
attacks etc etc) and CRC-32. However considering the application (i.e. to stop DECNET credentials
going over the wide Internet entirely in the clear and rudimentary identification of the end-points) I doubt
that there would be many attackers who would bother with the extra effort of attacking this compared to
the current completely unprotected setup.
But since this doesn't seem to interest that many people anyway I think I'll give it a miss.
Sampsa
On 25 Aug 2008, at 15:44, Paul Koning wrote:
Sampsa> My proposal is that each end point of a bridge connection
Sampsa> share a secret and use some form of symmetric encryption (say
Sampsa> AES in ECB mode) whilst communicating....
Sampsa> A CRC-32 (of the unencrypted frame) would be used to
Sampsa> determine the validity of the data.
Um, no.
I rather doubt this sort of thing is worth doing, but if you think
it's useful, you should use a design that has the right security
properties.
Doing crypto right is hard -- much harder than you might think. ECB
is never right; neither is CRC for integrity (in a crypto setting).
On the other hand, the right way already exists. Just turn on IPsec.
If you want to invent your own, you should study IPsec to see how it
is constructed, and understand why it is constructed that way.
Studying the prior art is a good idea. It helps to avoid building
stuff that doesn't work. And unfortunately there's plenty of that.
WEP is a classic example of a "security" system designed by people who
didn't know what they were doing, and didn't know that they didn't know.
paul
"Sampsa" == Sampsa Laine <sampsa at mac.com> writes:
Sampsa> Guys, I've had an idea for improving the usability and
Sampsa> security of the bridge: Encryption.
Sampsa> Now I realise that we're not dealing with a massively
Sampsa> high-security installation here with with HECnet but please
Sampsa> hear me out :)
Sampsa> My proposal is that each end point of a bridge connection
Sampsa> share a secret and use some form of symmetric encryption (say
Sampsa> AES in ECB mode) whilst communicating....
Sampsa> A CRC-32 (of the unencrypted frame) would be used to
Sampsa> determine the validity of the data.
Um, no.
I rather doubt this sort of thing is worth doing, but if you think
it's useful, you should use a design that has the right security
properties.
Doing crypto right is hard -- much harder than you might think. ECB
is never right; neither is CRC for integrity (in a crypto setting).
On the other hand, the right way already exists. Just turn on IPsec.
If you want to invent your own, you should study IPsec to see how it
is constructed, and understand why it is constructed that way.
Studying the prior art is a good idea. It helps to avoid building
stuff that doesn't work. And unfortunately there's plenty of that.
WEP is a classic example of a "security" system designed by people who
didn't know what they were doing, and didn't know that they didn't know.
paul
Yeah, that might be version 2 then :)
At the moment I'll just add some code to do the AES encryption and identity verification using CRC-32.
Sampsa.
On 25 Aug 2008, at 11:38, Johnny Billquist wrote:
Sampsa Laine wrote:
I figured I might just add some kind of identifier to the packet, and just grab the source address of the packet and use it as the new address, every time. Would this not work?
Well, you need to change the current code, since it don't work that way.
Also, you need to figure out which "old" source the packet came from, so that you don't change the source for the wrong other endpoint.
At my end, the bridge is talking to about 12 different other ends...
Johnny
Sampsa
On 25 Aug 2008, at 09:48, Johnny Billquist wrote:
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
Sampsa Laine wrote:
I figured I might just add some kind of identifier to the packet, and just grab the source address of the packet and use it as the new address, every time. Would this not work?
Well, you need to change the current code, since it don't work that way.
Also, you need to figure out which "old" source the packet came from, so that you don't change the source for the wrong other endpoint.
At my end, the bridge is talking to about 12 different other ends...
Johnny
Sampsa
On 25 Aug 2008, at 09:48, Johnny Billquist wrote:
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
I figured I might just add some kind of identifier to the packet, and just grab the source address of the packet and use it as the new address, every time. Would this not work?
Sampsa
On 25 Aug 2008, at 09:48, Johnny Billquist wrote:
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
Sampsa Laine wrote:
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Oh, it should definitely be easy. The data receive and data transmit are located in very few places.
There are some trickery in there that you additionally need to maybe think about, such as the code that tries to avoid receiving the same packets that are sent out.
Also, if you later plan to add functionality to enable sending meta-data, such as IP address changes, you need to change the contents of the packets, remove the verification of source address of data, maybe add some handling to make sure that address changes packets really are received (remember, this is all UDP).
There might be some other things to think about as well. Can't think of anything offhand, but one never knows... :-)
Johnny
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
OK, I'll have a go at it later on today if possible, this literally should not be TOO difficult to code in.
Sampsa
On 25 Aug 2008, at 09:27, Johnny Billquist wrote:
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
Sampsa Laine wrote:
Guys,
I've had an idea for improving the usability and security of the bridge: Encryption.
Now I realise that we're not dealing with a massively high-security installation here with
with HECnet but please hear me out :)
Gha! Feel free.
But I don't really want to fool around with that. My aim was to get something rather simple, that was easy to diagnose when problems occur. :-)
So I'll stick with my version for now. If someone else hacks something together, I might install it if it don't add much overhead to the data.
Johnny
