"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
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 :)
My proposal is that each end point of a bridge connection share a secret and use some
form of symmetric encryption (say AES in ECB mode) whilst communicating. This shouldn't
be terribly difficult to achieve (I might take a look at coding this myself once the rum-fuelled
haze from last night's Notting Hill Carnival wears off) in a fairly small amount of code.
If in addition a receiver of a valid packet constantly updated the target address of it's packets
to the source address of the last valid packet received the arrangement would not only ensure
that the host sending the data is in fact who they claim they are, but would enable a sending
host to change its IP address without borking things up, thus making our beloved bridge
usable on dynamic IP setups.
A CRC-32 (of the unencrypted frame) would be used to determine the validity of the data.
Example connection, Host A -> B
1. A receives a decnet frame on ethernet
2. A calculates a CRC-32 for the frame
3. A encrypts frame using shared secret with B
4. A appends CRC-32 from step 2 to the encrypted frame from step 3.
5. Frame is sent to B
6. B decrypts frame using shared secret with A
7. B calculates a CRC-32 of decrypted frame, compares with received CRC-32
8. Are they equal, if not abort.
9. Frame is valid, send onto ethernet.
10. B updates A's address to that of source address of the last frame.
Comments anyone?
Sampsa
On Sun, Aug 24, 2008 at 8:33 AM, Johnny Billquist <bqt at softjar.se> wrote:
Zane H. Healy wrote:
At 8:40 AM +0200 8/24/08, Johnny Billquist wrote:
Zane H. Healy wrote:
I assume 4.6 should have a separate tape for the DECnet install?
If you by that mean that DECnet isn't on the normal RSX distribution,
then yes.
If, on the other hand, you guess that the DECnet distribution itself is
multiple tapes, then no. It's only one tape in 4.6. It was only one tape in
4.5 as well. I can't remember if it was one or two tapes in 4.4 now.
I was simply asking if the DECnet distribution was separate from the RSX
distribution. Which means I'm lacking DECnet.
Ok. I wasn't sure. In the past, the DECnet distribution was on two (or
three) tapes. I don't think it have ever been on the same tapes as RSX
itself. And in the past, the RSX distribution came on two tapes as well, You
had the BRUSYS tape, and then the actual system. But that changed in the
last few releases as well.
Johnny
Hello!
Well I did mention that the Trailing-Edge ftp site was up to it's ears
in things and as it happens I didn't find the tapes for RSX, but I did
find stuff for RSTS:
Index of ftp://ftp.trailing-edge.com/pub/rsts_dists
Up to higher level directory
File: basic_plus_2_v2_1.zip 553 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_2.zip 282 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_3.zip 784 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_4.zip 1169 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_5.zip 1214 KB 10/30/2005 12:00:00 AM
File: basic_plus_2_v2_6.zip 1983 KB 10/30/2005 12:00:00 AM
File: basic_translator_rsts_fieldtext.tap.bz2 50 KB 10/30/2005 12:00:00 AM
File: bb-k400d-bc_pdp_f77_rsts_v5_0_c1983.tap.bz2 210 KB 10/30/2005
12:00:00 AM
File: bb-k400e-bc_pdp_f-77_rsts_v5_w_c1987.tap.bz2 303 KB 10/30/2005
12:00:00 AM
File: bb-k400e-bc_pdp_f77_rsts_v5_2_c1987.tap.bz2 303 KB 10/30/2005
12:00:00 AM
File: bb-k400f-bc_pdp_f77_rsts_v5_3_c1988.tap.bz2 300 KB 10/30/2005
12:00:00 AM
File: bb-p655c-bc_decmail11rsts_v3_0_c1986.tap.bz2 972 KB 10/30/2005
12:00:00 AM
File: bp2_v2_7.zip 1804 KB 10/30/2005 12:00:00 AM
File: c_v1_2.zip 1658 KB 10/30/2005 12:00:00 AM
File: cobol-11_v4_4.zip 606 KB 10/30/2005 12:00:00 AM
File: cobol-81_v2_3.zip 577 KB 10/30/2005 12:00:00 AM
File: decmail-11_v3_1.zip 461 KB 10/30/2005 12:00:00 AM
File: decnet-e_v2_0.zip 382 KB 10/30/2005 12:00:00 AM
File: decnet-e_v2_1.zip 811 KB 10/30/2005 12:00:00 AM
File: decnet-e_v4_0.zip 1113 KB 10/30/2005 12:00:00 AM
File: decnet-e_v4_1.zip 703 KB 10/30/2005 12:00:00 AM
File: f4p_rl02.zip 697 KB 10/30/2005 12:00:00 AM
File: f77_v5_3.zip 317 KB 10/30/2005 12:00:00 AM
File: fms11_v2_1.zip 321 KB 10/30/2005 12:00:00 AM
File: fortran-77_v5_4.zip 504 KB 10/30/2005 12:00:00 AM
File: fortran_iv_v2_8.zip 277 KB 10/30/2005 12:00:00 AM
File: microrsts.zip 3371 KB 10/30/2005 12:00:00 AM
File: pdp-11_c_for_rsts_e_t1_0_ft_7july89.tap.bz2 526 KB 10/30/2005
12:00:00 AM
File: pdp-11_c_for_rsts_e_t1_1_7_13_90.tap.bz2 1097 KB 10/30/2005 12:00:00 AM
File: pdp-11_c_for_rsts_e_v1_0_22_dec_89.tap.bz2 1003 KB 10/30/2005
12:00:00 AM
File: pdp-11_c_t1_0_fieldtest2_rstse.tap.bz2 762 KB 10/30/2005 12:00:00 AM
File: pdp11_c_rsts_v1_1.zip 1623 KB 10/30/2005 12:00:00 AM
File: rsts_e_v9_3_ft_update.tap.bz2 5054 KB 10/30/2005 12:00:00 AM
File: rsts_v8_csp180.zip 2289 KB 10/30/2005 12:00:00 AM
File: rsts_v8_sysgnl.zip 3484 KB 10/30/2005 12:00:00 AM
File: rsts_v8_update-g.zip 3397 KB 10/30/2005 12:00:00 AM
File: rsts_v9_0_install.zip 2331 KB 10/30/2005 12:00:00 AM
File: rsts_v9_1_install.zip 4016 KB 10/30/2005 12:00:00 AM
File: rsts_v9_2_install.zip 5320 KB 10/30/2005 12:00:00 AM
File: rsts_v9_3_install.zip 5900 KB 10/30/2005 12:00:00 AM
File: rsts_v9_4_install.zip 6636 KB 10/30/2005 12:00:00 AM
File: rsts_v9_5_install.zip 7297 KB 10/30/2005 12:00:00 AM
File: rsts_v9_6_install.zip 7883 KB 10/30/2005 12:00:00 AM
File: rsts_v9_library.zip 4852 KB 10/30/2005 12:00:00 AM
File: rstse_v9_3_field_test.tap.bz2 5013 KB 10/30/2005 12:00:00 AM
File: rstse_v9_6_final_field_test.tap.bz2 6908 KB 10/30/2005 12:00:00 AM
File: rstsv7gen.tar.Z 5063 KB 10/30/2005 12:00:00 AM
File: rstsv9_source.zip 7980 KB 10/30/2005 12:00:00 AM
File: rstsv9_src.zip 7980 KB 10/30/2005 12:00:00 AM
And everything can be found at the location given above.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature was once found posting rude
messages in English in the Moscow subway."
Zane H. Healy wrote:
At 8:40 AM +0200 8/24/08, Johnny Billquist wrote:
Zane H. Healy wrote:
I assume 4.6 should have a separate tape for the DECnet install?
If you by that mean that DECnet isn't on the normal RSX distribution, then yes.
If, on the other hand, you guess that the DECnet distribution itself is multiple tapes, then no. It's only one tape in 4.6. It was only one tape in 4.5 as well. I can't remember if it was one or two tapes in 4.4 now.
I was simply asking if the DECnet distribution was separate from the RSX distribution. Which means I'm lacking DECnet.
Ok. I wasn't sure. In the past, the DECnet distribution was on two (or three) tapes. I don't think it have ever been on the same tapes as RSX itself. And in the past, the RSX distribution came on two tapes as well, You had the BRUSYS tape, and then the actual system. But that changed in the last few releases as well.
Johnny
