On 4/10/2013 1:50 PM, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 4/10/13 12:17 PM, Harris, Jeffrey E. wrote:
-----Original Message----- From: Christopher Schultz
[mailto:ch...@christopherschultz.net] Sent: Wednesday, April 10,
2013 12:09 PM To: Tomcat Users List Subject: Re: Better SSL
connector setup
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
André,
On 4/9/13 11:54 AM, André Warnier wrote:
Harris, Jeffrey E. wrote:
Chris,
-----Original Message----- From: Christopher Schultz
[mailto:ch...@christopherschultz.net] Sent: Tuesday, April
09, 2013 10:01 AM To: Tomcat Users List Subject: Re: Better
SSL connector setup
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Jeffrey,
On 4/9/13 8:17 AM, Harris, Jeffrey E. wrote:
-----Original Message----- From: André Warnier
[mailto:aw@ice-
sa.com]
Sent: Tuesday, April 09, 2013 6:04 AM To: Tomcat Users
List Subject: Re: Better SSL connector setup
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
You can improve the performance of the existing RS-232
modem pool by doing some ROT-13 and Fourier transforms
prior to data
encoding.
However, this does require the equivalent capability on
the receiving side.
- -1
Using ROT-13 can certainly improve the security of your
data in-transit and *is* a NIST recommendation, but it
unfortunately
does
not improve performance as it introduces an additional
operation in the pipeline. As usual, real security is a
trade-off between convenience (here, speed) and actual
security (the superior cipher algorithm ROT-13). I believe
recent versions of OpenSSL (0.9.1c?) include the new
ROT13-XOR- MD2 cipher, but since it is optimized
for
8-bit processors you need to make sure to have a modern CPU
-- I recommend one of the "DX2" Intel processors.
Okay, it does not improve performance, but it sure confuses
the heck out of man-in-the-middle attacks!
As for Fourier transforms, that's just security through
obscurity (though it's pretty good obscurity). "Fast"
Fourier transforms also work best with data sizes that are
powers-of-two in length and so your throughput can
experience odd pulsing behavior while your buffers fill
waiting to be transformed. Unless you have one of the
aforementioned "DX2" style processors coupled with a
V.22bis-capable device, you are probably not going to be
able to keep up with all the traffic your Gopher server is
likely to generate.
Well, I was focusing on performance here, not security. And
if I
use
my Amiga 1000, I can invoke hardware security because of the
non-standard RS-232 port (just try and connect a regular
RS-232
cable
to that system, and see how quickly the modem shorts out!),
and because the instruction set uses Motorola 68000
instructions, not
DX2
Intel instructions.
That's not really security either. Any common optical RS-232
isolator
(like the one shown here :
http://www.commfront.com/rs232-rs485-rs422-serial-converters/RS232-
Iso
lator-7-wire.htm)
will easily overcome that issue. I started using these
everywhere after I blew up the line drivers of my Soroc
terminal a couple of times by forgetting to switch it off
before I unplugged it. I don't know what the optical nature of
the isolator does to the security by obscurity aspect though, I
suspect that it may make a man-in-the-middle attack easier (as
long as the man is not really in the middle physically of
course). For SSL however, due to the higher bitrate, I would
recommend a conversion to RS485 (with this e.g. :
http://www.szatc.com/english/showpro.asp?articleid=169) (beware
of embedded Trojans though).
USB is just a fad. Stick with SCSI unless you want to have a
whole lot of useless hardware in 18 months.
Also, for your Amiga, you may want to consider swapping the
68000 processor by a 68010. It is pin-compatible and provides a
significant speed boost, maybe enough to allow you to switch
from a 48-bit encryption scheme to a 128-bit scheme.
Don't forget to install the Microsoft High Encryption pack, or
your browsers won't be able to decrypt that stuff. I think you
have to register with the DOD in order to deploy ciphers of that
strength.
- -chris
I will just convert everything into machine code. The Motorola
processors and AmigaOS use Big-Endian, and Intel processes use
Little-Endian, so that will just confuse anyone who uses Intel
hardware and most operating systems, particularly if I just overlay
the results with the Beatles' "Helter Skelter" played backwards and
sampled at 11.025KHz.
Get yourself a DEC Alpha and write an algorithm that switches
endian-ness halfway through the process. Good luck debugging that.
- -chris
OK, I guess I can grab a TOPS-20 emulator and write 10-bit bytes (in
Algol). I don't have any PDP 8 or 10 hardware lying around any more.
I do still have my PDP 8i/8L assembler manual somewhere around here
(along with the appropriate DECtape).
. . . . just my 10-bit cents.
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
