List of Archived Posts
2003 Newsgroup Postings (08/17 - 09/07)
- One big box vs. many little boxes
- Digital signature and Digital Certificate
- S/360 Engineering Changes
- S/360 Engineering Changes
- S/360 Engineering Changes
- Multiple ECDSA signatures with the same random nonce
- The Original Interlock Protocol (what is...)
- One big box vs. many little boxes
- 14443 protocol information
- how long does (or did) it take to boot a timesharing system?
- how long does (or did) it take to boot a timesharing system?
- how long does (or did) it take to boot a timesharing system?
- Why are there few viruses for UNIX/Linux systems?
- Cost of patching "unsustainable"
- Cost of patching "unsustainable"
- downsizing (euphemisms)
- how long does (or did) it take to boot a timesharing system?
- how long does (or did) it take to boot a timesharing system?
- ARP cache for multicast & broadcast packets?
- Secure OS Thoughts
- Secure OS Thoughts
- Secure OS Thoughts
- Secure OS Thoughts
- Why more than 1 hole in FW for IPSec
- RSA vs AES
- IBM Manuals from the 1940's and 1950's
- Secure OS Thoughts
- RSA vs AES
- RSA vs AES
- Offshore IT
- Secure OS Thoughts
- IBM Manuals from the 1940's and 1950's
- RSA vs AES
- RSA vs AES
- Thoughts on Utility Computing?
- RSA vs AES
- Proposal for a new PKI model (At least I hope it's new)
- Thoughts on Utility Computing?
- Thoughts on Utility Computing?
- Port Assignment- OT in a Small Way
- The real history of computer architecture: the short form
- Secure OS Thoughts
- Thoughts on Utility Computing?
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- OSI not quite dead yet
- IBM Manuals from the 1940's and 1950's
- Thoughts on Utility Computing?
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- Proposal for a new PKI model (At least I hope it's new)
- Offshore IT ... again
- Proposal for a new PKI model (At least I hope it's new)
- Thoughts on Utility Computing?
- Thoughts on Utility Computing?
- Proposal for a new PKI model (At least I hope it's new)
- Can you use ECC to produce digital signatures? It doesn't see
- IBM Manuals from the 1940's and 1950's
- Seven of Nine
- Can you use ECC to produce digital signatures? It doesn't see
- Strength of RSA with known plain-text
One big box vs. many little boxes
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One big box vs. many little boxes
Newsgroups: comp.arch
Date: Sun, 17 Aug 2003 15:50:56 GMT
"Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
This could be as well because TCP/IP was not designed in in a separated
layers model at first, and it would be rather a good exemple of how much
difficult it is when you don't have layers at first glance...
arpanet had single homogeneous infrastructure .... in large part
relying on IMPs. TCP was available ... but there was really no such
thing as gateways and heterogeneous networking.
one of my assertions is that the internal network was larger than the
arpanet/internet until sometime mid-85 ... in large part because the
internal network nodes effectively had gateway function almost since
the start .... which didn't show up until the "internet protocol"
layer switch-over on 1/1/83.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Digital signature and Digital Certificate
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Digital signature and Digital Certificate
Newsgroups: comp.security.firewalls
Date: Sun, 17 Aug 2003 18:34:45 GMT
slightly related thread:
http://www-unix.gridforum.org/mail_archive/security-wg/2003/03/msg00002.html
original reference in above at:
http://www.garlic.com/~lynn/aadsm13.htm#20
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
S/360 Engineering Changes
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 Engineering Changes
Newsgroups: alt.folklore.computers
Date: Sun, 17 Aug 2003 20:03:02 GMT
ab528@freenet.carleton.ca (Heinz W. Wiggeshoff) writes:
Does anyone else agree that the
Internet/WWW design is fundamentally
flawed? Some piece of shit can take
over command of YOUR computer and
make it sing and dance. In all the years
of connecting to IBM m/f remotely, (from
APL\360 to VM in the 1990's), I never
even heard of virus or worm infections.
Perhaps the shit design work out of
Redmond has a lot to do with SANlove,
(or whatever it's called).
we shot/identified a vulnerability about 30 years ago on the internal
network ... where somebody sent a CMS "exec" file as part of some
email ... that had the same filename as a standard CMS command. The
cms (shell) command lookup process did a search that involved synonym
table, exec file, module file, and then internal kernel api (and files
were searched for in proscribed order). In effect, it was possible to
get a person to load an exec file (script file) ... with the name of a
standard common command ... and have it executed automagically, the
next time ther person typed in that command.
at that point (remember this was 30 years ago) ... it was concluded
that you had to have procedures that avoided (automagically) executing
scripts and/or binaries arriving over the network.
at a recent cybersecurity conference ... one of the panel claimed that
currently about exploits:
1/3rd are buffer overflows (primarily result of programmers being
encouraged to shoot themselves in the foot because of characteristics
of c-language string handling semantics).
1/3rd are scripting/executing of files arriving over the network
1/3rd are social engineering
prior to the (latest) introduction of network-originating
scripting/execution, the exploits were pretty evenly (c-language)
buffer overflows and social engineering. there was a paper presented
last year that claimed Multics has never had a known case of buffer
overflow. It isn't so much that PL/I (multics) language was relying on
range/bounds checking ... but the underlying semantics for handling
strings is totally different (from C library routines). It wasn't so
much that it was impossible to run over a buffer ... but the length
related semantics made it much less likely to happen.
social engineering typically involves inducing a person to give up
some shared-secret based piece of information .... aka some
information and/or values that enables the crook to fraudulent perform
some operation(s).
it is related to making rules that (shared-secre) password-based
security demands that nobody uses the same password in multiple
contexts (aka your employee login password shouldn't be the same as
your local personal ISP login, shouldn't be the same as your home
banking login). this gives rise to some people nominally having
requirements for large tens or hundred plus (shared-secret) passwords.
many of the human factors related to rules about re-using passwords
and never divulging information (in social engineering scenarios) are
similar; aka you can have all the rules you want and they still get
violated.
One approach to both the social engineering and hundreds of passwords
issue is to transition away from shared-secret based infrastructures
(aka a paradigm where if a person doesn't know something ... then it
can't be divulged and/or shared)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
S/360 Engineering Changes
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 Engineering Changes
Newsgroups: alt.folklore.computers
Date: Sun, 17 Aug 2003 20:11:03 GMT
oh yes, misc. past posts on automagic scripting
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#34 virus attack on banks (was attack on paypal)
http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002g.html#27 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
http://www.garlic.com/~lynn/2003j.html#8 A Dark Day
lots of general fraud, exploits, and vulnerability discussions:
http://www.garlic.com/~lynn/subintegrity.html#fraud
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
S/360 Engineering Changes
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 Engineering Changes
Newsgroups: alt.folklore.computers
Date: Sun, 17 Aug 2003 22:23:23 GMT
"Glen Herrmannsfeldt" writes:
This reminds me (because it involves exec) of one of my early
programs run under CMS. I was writing a PL/I program to sort some
data, which used a SORT command that the version of PL/I had. It
seemed to make sense that my program should be named SORT, both in
its file name, and the name of the main procedure, SORT: PROC
OPTIONS(MAIN).
I found a mysterious infinite loop that I couldn't find, so finally
I tried changing both the file name and PROC name.
That was before I knew the rules for CMS executing programs. I
don't believe that MVS would have the same problem, though I am not
sure about that.
cms possibly inherited human factors from ctss ... allowing ultimate
tailorability to the individual's desired environment (which doesn't
mean that you couldn't shoot yourself in the foot); while MVS
effectively demanded that the person adapt to the system.
original CMS ... all commands were svc202 with an 8byte symbolic name.
typed in commands were translated to svc202 format .... programming
api used svc202 format/api.
that name could be looked up in a synonym/abbreviation table ... that
the user could specify entries in.
then filesystems were scanned in proscribed order for EXEC file with
that name, then filesystems were scanned for MODULE (binary
executable) file with that name. Finally, it looked to see if there
was a kernel interface with that name. Later VM/370 added a fastpath
to CMS for kernel API ... svc203 which specified a code that was
specific for selecting kernel functions.
in effect, something like "script" could be developed in the users's
own filesystem and invoked transparently the same as if it was a
system command. at some point the program could be moved to the area
with standard system commands ... and voila the whole community now
has document formating routine.
this human factors useability feature appeared to contribute
significantly to development and migration to more general
availability of all sorts of feature/function in the cms environment
(aka somebody could develop something for their own use and it could
transparently be made available for wider use ... if found useful) ...
aka a single, uniform, consistent interface for invoking all commands
and programs.
misc. past posts on cms command lookup:
http://www.garlic.com/~lynn/2001c.html#88 Unix hard links
http://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
http://www.garlic.com/~lynn/2003l.html#2 S/360 Engineering Changes
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Multiple ECDSA signatures with the same random nonce
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple ECDSA signatures with the same random nonce
Newsgroups: sci.crypt
Date: Sun, 17 Aug 2003 22:43:11 GMT
hei123@gamebox.net (Ruaide Berti) writes:
Sorry from this questions, but I don't understand the math behind
encryption.
think along the lines of solving two equations in two unknowns ... if
both private key and random number are constant. FIPS186 objective is
to have the random number, never the same.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
The Original Interlock Protocol (what is...)
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Original Interlock Protocol (what is...)
Newsgroups: sci.crypt
Date: Mon, 18 Aug 2003 14:23:36 GMT
"John E. Hadstate" writes:
As I explained before, the protocol's advertised purpose was to
defeat the MITM attack. But, a protocol that requires a shared-secret to be established out-of-band with respect to the protocol
itself is not solving anything. It's merely relying on the
out-of-band transfer to defeat MITM.
check on various MITM countermeasures involving some sort of
out-of-band transfer. SSL certificates & public key operations
.... rely on the certifying authority's public key to be locally
registered ... requiring out-of-band transfer (common practice of
building it into the browser and it is transfered as part of
installing the browser). Essentially there is some atomic unit of
trust that all the other pieces are scaffolded on top of (while the
CA's public key isn't a shared-secret .... it is a basic trust
building block that required out-of-band transfer).
slightly related:
http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
http://www.garlic.com/~lynn/2003l.html#1 Digital signature and Digital Certificate
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
One big box vs. many little boxes
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One big box vs. many little boxes
Newsgroups: comp.arch
Date: Thu, 21 Aug 2003 17:56:42 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Furthermore, I have been told by senior representatives of all
the major vendors that their policy is to use common components
and designs whereever practical. I am fully aware that a company
like IBM has many incompatible policies, but I can assure you that
at least the IBM SP range uses a great many components in common
with its RS/6000 workstation range.
similar subject in "downsizing" thread going on in real-time over in
ibm-main ng/list ... some number making similar claims ... although
one person who claims has seen lots of actual numbers under NDAs
... and can't repeat them.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
14443 protocol information
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 14443 protocol information
Newsgroups: alt.technology.smartcards
Date: Thu, 21 Aug 2003 18:00:34 GMT
"curok" writes:
Ummm, sorry if i misled you. I think i'm wrong about the ISO 7816.
ISO7816 is for contact cards and ISO14443 is for contactless. Did
you read the part 4 of ISO 14443 which states the transmission
protocols? I don't know for sure but in part 4 of ISO7816, there
are some commands that let you read, write data to the card. I
don't know if it holds true for 14443.
14443 proximity standard actually has a couple of variations
(effectively originating from different vendors). some vendors that
have done combo-chips .... will have wrapped 14443 circuits around
7816 core ... so that applications developed on 7816 may find it
somewhat transparent whether operating in 14443 or 7816.
big issue in 14443 can be power profile for anything very complex
since the chip is drawing the power from the air.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
how long does (or did) it take to boot a timesharing system?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Aug 2003 00:01:31 GMT
Lon Stowell writes:
I dimly remember one of the blurbs for a major VTAM release in the
late 80's [V3R2] mentioning the reduction of bringup of a major
SNA network complex to something on the order of 4 hours compared
to pretty close to a day beginning at IPL of MVS. This was bringing
up one or more MVS's, downloading all of the NCP's, etc. Don't
recall that clearly but don't think it included bringing up any
IMS or CICS on top of all this.
one of the issues that i remember was some issue with VTAM page
thrashing as part of restart.
one of the characteristics of the pu4/pu5 emulator was that all the
sessions and resources appeared to be owned someplace else
(effectively it was a distributed packet, no-single-point-of-failure
implementation ... on top of which pu4/pu5 were emulated).h
misc. refs:
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
random other rfs:
http://www.garlic.com/~lynn/94.html#33a High Speed Data Transport (HSDT)
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/2000c.html#51 WHAT IS A MAINFRAME???
http://www.garlic.com/~lynn/2001b.html#49 PC Keyboard Relics
http://www.garlic.com/~lynn/2001e.html#55 Pre ARPAnet email?
http://www.garlic.com/~lynn/2001i.html#31 3745 and SNI
http://www.garlic.com/~lynn/2001n.html#9 NCP
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002.html#15 index searching
http://www.garlic.com/~lynn/2002.html#28 Buffer overflow
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002b.html#54 Computer Naming Conventions
http://www.garlic.com/~lynn/2002b.html#59 Computer Naming Conventions
http://www.garlic.com/~lynn/2002c.html#41 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002c.html#42 Beginning of the end for SNA?
http://www.garlic.com/~lynn/2002h.html#48 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002i.html#58 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002k.html#20 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#37 RCA Spectra architecture
http://www.garlic.com/~lynn/2003.html#9 Mainframe System Programmer/Administrator market demand?
http://www.garlic.com/~lynn/2003.html#17 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#67 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003b.html#5 Card Columns
http://www.garlic.com/~lynn/2003b.html#8 Card Columns
http://www.garlic.com/~lynn/2003b.html#16 3745 & NCP Withdrawl?
http://www.garlic.com/~lynn/2003c.html#28 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003c.html#30 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#20 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#49 unix
http://www.garlic.com/~lynn/2003d.html#67 unix
http://www.garlic.com/~lynn/2003d.html#73 unix
http://www.garlic.com/~lynn/2003e.html#4 cp/67 35th anniversary
http://www.garlic.com/~lynn/2003e.html#74 Security Certifications?
http://www.garlic.com/~lynn/2003j.html#2 Fix the shuttle or fly it unmanned
http://www.garlic.com/~lynn/2003j.html#29 IBM 3725 Comms. controller - Worth saving?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
how long does (or did) it take to boot a timesharing system?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Aug 2003 00:08:46 GMT
Larry__Weiss writes:
I'd like to hear accounts of how long it took to bring up some
of the old timesharing systems. I was never a part of the "priesthood"
behind the locked doors, so I don't know from experience (my initial
timeshared system experience as a user was on a CDC-6600 at UT Austin).
cp/67 would nominally be on the order of 2-3 minutes .... vm/370 was
similar. part of the issue in early cp/67 was to make it automated so
that system could run unattended.
one of the supposedly justifications for the work on the multics
fast/new filesystem ... was the comparison to cp/67 ... where somebody
at mit introduced a bug ... which when a specific circumstance was
encountered ... there was a system failure, a full system dump was
automatically taken and the system automatically rebooted. this
supposedly happened 26 times during the course of one day. by
comparison, multics was taken an hour or more to reboot (there were
enuf hours in the day for the system to fail and reboot and be back,
up and running, providing service ... 26 times in one day).
past threads on the subject:
http://www.garlic.com/~lynn/99.html#86 1401 Wordmark?
http://www.garlic.com/~lynn/99.html#107 Computer History
http://www.garlic.com/~lynn/99.html#113 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#135 sysprog shortage - what questions would you ask?
http://www.garlic.com/~lynn/2000b.html#77 write rings
http://www.garlic.com/~lynn/2001e.html#7 Blame it all on Microsoft
http://www.garlic.com/~lynn/2002l.html#55 The problem with installable operating systems
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003k.html#55 S/360 IPL from 7 track tape
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
how long does (or did) it take to boot a timesharing system?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Aug 2003 00:39:34 GMT
Lon Stowell writes:
The blurb I am thinking of was one of the semi-official IBM pubs for
the release. Problem is there were so many of them, as this IIRC,
was the big VTAM/NCP release to first support PU 2.1 with
independent LU's. Not so much too lazy to dig it out, as that
particular stack of yellow and red books is in an anonymous box
stacked in an unknown location with a considerable number of other
anonymous boxes in a pile dating back to prior to 1989 when I left
Amdahl and mainframe networking more or less forever. There are
probably creepy crawlies in the boxes by now.
this was early to mid 80s studies in conjunction with ims hot standby
.... while IMS might be there "instantaneously" ... it could take 4-6
hours to get large number of VTAM sessions back .... there were lots
of issues with VTAM non-linear slowdowns ... the first couple sessions
came back relatively quickly ... but then things got progressively
slower, very, very quickly.
random past ims hot standby refs:
http://www.garlic.com/~lynn/98.html#35a Drive letters
http://www.garlic.com/~lynn/98.html#37 What is MVS/ESA?
http://www.garlic.com/~lynn/98.html#40 Comparison Cluster vs SMP?
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#77 Are mainframes relevant ??
http://www.garlic.com/~lynn/99.html#92 MVS vs HASP vs JES (was 2821)
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/2000.html#13 Computer of the century
http://www.garlic.com/~lynn/2000c.html#45 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#47 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2000f.html#54 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001c.html#69 Wheeler and Wheeler
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#2 Block oriented I/O over IP
http://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001g.html#44 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001g.html#46 The Alpha/IA64 Hybrid
http://www.garlic.com/~lynn/2001j.html#23 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001k.html#13 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#47 five-nines
http://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002b.html#54 Computer Naming Conventions
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
http://www.garlic.com/~lynn/2002g.html#48 Why did OSI fail compared with TCP-IP?
http://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002j.html#45 M$ SMP and old time IBM's LCMP
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002o.html#68 META: Newsgroup cliques?
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002q.html#35 HASP:
http://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system
http://www.garlic.com/~lynn/2003.html#40 InfiniBand Group Sharply, Evenly Divided
http://www.garlic.com/~lynn/2003h.html#56 The figures of merit that make mainframes worth the price
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Why are there few viruses for UNIX/Linux systems?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are there few viruses for UNIX/Linux systems?
Newsgroups: comp.os.linux.security,alt.folklore.computers
Date: Sat, 23 Aug 2003 18:12:55 GMT
Tim Haynes <usenet-20030823@stirfried.vegetable.org.uk> writes:
I know of no native "layers of virtualisation" system in any M$loth OS,
that's one of the problems. Around here, we have chroot() with GRsecurity
patches for further security, jail() on BSE, ctx server patches and UML.
Take your pick, how do you want it to be "not the real machine" running
your services today?
MSware: VMware. Well, we got that too.
both cp/67 and vm/370 have had relatively good security records with
their virtual machine approach. There has been some discussion that
the B3(?) vax/vms rating was done by creating a virtual machine
abstraction below vms ... for various security domain and isolation
issues.
note that just about all of the mainframes now have flavor of vm/370
subset built into the hardware of the machine ... and just about all
mainframe installations (MVS, VM, Linux, etc) now are run in these
virtual machines aka virtual machine subset called LPARs (or logical
partitions). LPARS essentially grew out of the expanding VM "microcode
assists" that originally appeared on 370/158 (early 70s) .... until
there was sufficient amount of virtual machine microcode assists
embedded into the hardware of the machine ... that it was possible to
provide virtual machine subset (LPARs) even when not running full
blown virtual machine operating system.
The LPAR settings are typically setup under control of a "service
processor" that provides interfaces, diagnostics, and control of many
of the hardware features. However, service processors in their own
right could also have operating systems. The mainframe 3090 had a pair
of 4361s for service processors .... both running a highly modified
version of VM/370 release 6 ... and all the service panels and
interfaces were mostly implemented in IOS3270, an application running
under CMS (in virtual machine under VM/370).
misc. past LPAR references:
http://www.garlic.com/~lynn/98.html#45 Why can't more CPUs virtualize themselves?
http://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#8 Computer of the century
http://www.garlic.com/~lynn/2000.html#63 Mainframe operating systems
http://www.garlic.com/~lynn/2000.html#86 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#50 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#51 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#52 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#61 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000b.html#62 VM (not VMS or Virtual Machine, the IBM sort)
http://www.garlic.com/~lynn/2000c.html#8 IBM Linux
http://www.garlic.com/~lynn/2000c.html#50 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#76 Is a VAX a mainframe?
http://www.garlic.com/~lynn/2000f.html#78 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2000g.html#3 virtualizable 360, was TSS ancient history
http://www.garlic.com/~lynn/2001b.html#72 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001e.html#5 SIMTICS
http://www.garlic.com/~lynn/2001f.html#17 Accounting systems ... still in use? (Do we still share?)
http://www.garlic.com/~lynn/2001f.html#23 MERT Operating System & Microkernels
http://www.garlic.com/~lynn/2001h.html#2 Alpha: an invitation to communicate
http://www.garlic.com/~lynn/2001h.html#33 D
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2001n.html#32 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002c.html#53 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?)
http://www.garlic.com/~lynn/2002d.html#31 2 questions: diag 68 and calling convention
http://www.garlic.com/~lynn/2002e.html#25 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2002e.html#75 Computers in Science Fiction
http://www.garlic.com/~lynn/2002f.html#6 Blade architectures
http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips
http://www.garlic.com/~lynn/2002n.html#6 Tweaking old computers?
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002n.html#28 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#0 Home mainframes
http://www.garlic.com/~lynn/2002o.html#15 Home mainframes
http://www.garlic.com/~lynn/2002o.html#16 Home mainframes
http://www.garlic.com/~lynn/2002o.html#18 Everything you wanted to know about z900 from IBM
http://www.garlic.com/~lynn/2002p.html#4 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002p.html#40 Linux paging
http://www.garlic.com/~lynn/2002p.html#44 Linux paging
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2002p.html#55 Running z/VM 4.3 in LPAR & guest v-r or v=f
http://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
http://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#15 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003.html#56 Wild hardware idea
http://www.garlic.com/~lynn/2003c.html#41 How much overhead is "running another MVS LPAR" ?
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003k.html#9 What is timesharing, anyway?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Cost of patching "unsustainable"
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cost of patching "unsustainable"
Newsgroups: comp.arch
Date: Sat, 23 Aug 2003 17:59:48 GMT
"Stpehen Fuld" writes:
Yes, IIRC that ws the one that the former IBM Federal System Division won
the contract and got so far behind schedule and over budget that it was
clear that it would never get done in any reasonably time and the program
was cancelled.
i believe that large percentage of federal agencies have had
modernization projects starting (at least) in the '80s and extending
thru the 90s. some of those modernization projects may be in the 4th
or 5th generation ... with some set of the vendors the same every time
... but prime contractor may change from generation to
generation. i've heard some wonder if the modernization activities
haven't turned into modern version of public works projects that might
not just go on forever.
i believe census was one of the better successes in the late '90s.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
Cost of patching "unsustainable"
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cost of patching "unsustainable"
Newsgroups: comp.arch
Date: Sun, 24 Aug 2003 19:44:52 GMT
"del cecchi" writes:
Easily could have been FSD. IBM is not immune from biting off more than
they can chew/ promising more than they can deliver/ totally screwing up
a project, fer sure.
the "first" FAA project was FSD ... J.F., A.F., some of the others.
At least some of the later "modernization" had a design that all
failure modes could be masked by low-level hardware (& software)
redundancy and recovery. Turns out that FAA had some number of
failure modes that occur at the domain/application level. Telling a
bunch of people that they don't have to design/implement in the
application for failure/recovery ... because all such things will be
automagically handled for them ... led to some number of problems.
By that time, FSD also had a very high precentage of contract &
gov. business management people ... also large number of people very
experienced in GML word-smithing for writing contracts, RFI/RFP
answers, etc. There was no problem that couldn't be solved by applying
the appropriate amount of business and management control.
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
downsizing (euphemisms)
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: downsizing (euphemisms)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 26 Aug 2003 05:27:25 GMT
john_w_gilmore@MSN.COM (john gilmore) writes:
To ensure that IBM had't jacked up the acronym and put a new
interpretation under it, as it sometimes does, I checked a very
recent DB2 manual; and, yes, the 'S' in SQL does still mean
'structured'. As such it also means nothing. It is now empty of
anything but notionally positive feeling tone, as 'unstructured' and
'anarchic' are empty of anything but negative feeling tone.
past references to sequel, sql, quel, qbe
http://www.garlic.com/~lynn/2002e.html#44 SQL wildcard origins?
http://www.garlic.com/~lynn/2002o.html#70 Pismronunciation
http://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?
--
Anne & Lynn Wheeler | lynn@garlic.com - http://www.garlic.com/~lynn/
Internet trivia, 20th anniv: http://www.garlic.com/~lynn/rfcietff.htm
how long does (or did) it take to boot a timesharing system?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Aug 2003 19:23:47 GMT
sarr@timepilot.gpcc.itd.umich.edu (Sarr J. Blumson) writes:
Let me do a terminology check here. A former boss insisted that the
system we were building had to boot in 30 seconds, because "that's what
VM did." But the VM system we used for support actually took 20-30
minutes to get the supporting virtual machines started to where it
could do useful work. I have to idea whether this was typical or
because of local issues.
in old vanilla time-sharing .... it was time to a any user could log
on; numerous types of service offerings could require require that
they come up and initialize which might take arbritrary long period of
time. normal cms had core-image saved just prior to writing the cms
ready message. normal user login then invoked the "by name" saved
image of cms and it was essentially almost instantaneous after the
user logged on.
if there was a virtual guest operating system that needed to come up
after VM was up ... most of the virtual guest operating systems could
take tens of minutes, including possibly some amount of human
interaction.
besdies that ... other types of "supporting" virtual machines
(non-traditional guest operating systems) ... had lots of instances of
applications ... where the application writers frequently did not pay
as much attention to startup timeliness (as the work that went into
original cp and cms)
some customers did experiment with saving core-images of os/360 MVT,
essentially after nearly all its startup initialization had been
performed ... so that it was accessable "by name" under cp with pretty
timely startup.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
how long does (or did) it take to boot a timesharing system?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Aug 2003 20:04:25 GMT
Tom Van Vleck writes:
One reason that CP-67 could boot so quickly in the early
days, 1969 or so, when I used it at MIT, was that it didn't
salvage the file system(s). CMS users each had a simulated
physical disk (P-disk) as part of their virtual machines.
The CMS file system ran inside the VM and read and wrote
files using a fairly conservative policy, such that
interrupting execution rarely destroyed the whole file
system. Users were responsible for backing up their own
P-disks. After a crash, CP ran a salvager called the
Buzzard that punched accounting cards for interrupted
sessions, and then just restarted. People had to log in
again and re-IPL CMS, and see if their files were OK.
Usually they were.
Occasionally, a user would come to me in a panic, because
something went wrong and all their files were lost. One
way to cause this was to scramble low memory in the VM: in
those days CMS and the user application ran in the same
virtual memory space and an array bounds error could cause
user data to overwrite the CMS system's tables including
I/O buffers, and still let them be written to the P-disk.
These users were astounded and furious that there was
nothing I could do to retrieve their files.
CMS used shadowing for all its metadata updates for each filesystem.
It would maintain the metadata for each filesystem in virtual memory
and then on commit, write the (changed) metadata to new disk locations
and then update the MFD record to indicate the new metadata position.
If there was a failure before the MFD was updated .... a restart would
see the previous/old metadata. If there was a bug ... that scrambled
the metadata, but didn't abort CMS ... CMS would write the scrambled
metadata to disk and update the MFD for that filesystem (note this was
an individual's filesystem not other users' filesystems). Most CMS
"system" filesystems were only accessable by normal users as read-only
... so they weren't able to affect other than their private
filesystem(s).
There was a failure mode in IBM mainframe hardware where it was
possible to have an unrecoverable write error at the same time as the
power failure (lost the whole machine) ... which, if it occured at the
same time as the MFD record was being written ... that filesystem
could be scrambled because the MFD was scrambled. One of the features
in the "enhanced" (EDF) filesystem was that there were two alternating
copies of the MFD. After writing all the filesystem's metadata (to new
location), it would write a new MFD record with an updated version
number to the alternate location (i.e. which made the alternate, the
current active location). On restart, CMS would read both MFDs
records, and take the valid one with the most recent version number.
Early CP/67 only came with DDR which was used by some shops to do
periodic full-pack, disk image backups ... possibly only on a weekly
basis.
In the '70s, I did a incremental file backup that was used at several
internal locations and went thru a number of versions before it was
made available as a product as Workstation Data Save (WDSF, when
became ADSM and now TSM). misc. backup posts
http://www.garlic.com/~lynn/submain.html#backup
misc. past posts about cms MFD &/or "EDF" filesystem operation
http://www.garlic.com/~lynn/99.html#53 Internet and/or ARPANET?
http://www.garlic.com/~lynn/2000b.html#80 write rings
http://www.garlic.com/~lynn/2001c.html#76 Unix hard links
http://www.garlic.com/~lynn/2001m.html#57 Contiguous file system
http://www.garlic.com/~lynn/2001m.html#58 Contiguous file system
http://www.garlic.com/~lynn/2001n.html#92 "blocking factors" (Was: Tapes)
http://www.garlic.com/~lynn/2002b.html#62 TOPS-10 logins (Was Re: HP-2000F - want to know more about it)
http://www.garlic.com/~lynn/2002d.html#5 IBM Mainframe at home
http://www.garlic.com/~lynn/2002q.html#21 Beyond 8+3
http://www.garlic.com/~lynn/2002q.html#25 Beyond 8+3
http://www.garlic.com/~lynn/2003b.html#42 VMFPLC2 tape format
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
ARP cache for multicast & broadcast packets?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ARP cache for multicast & broadcast packets?
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 27 Aug 2003 14:00:55 GMT
Fernando Gont writes:
Go to http://www.rfc-editor.org, and search for the ARP specification.
It might be updated by the Host Requirements RFC, so have a look at
it, too.
and from
http://www.garlic.com/~lynn/rfcietff.htm
click on Term (term->RFC#) in RFCs listed by
and then click on "ARP"
address resolution protocol (ARP )
see also address resolution
2835 2834 2625 2390 2320 2225 1868 1735 1577 1433 1390 1374 1293 1051
1027 903 826
clicking on the RFC number in the above brings up the summary in
the lower frame:
826 S
Ethernet Address Resolution Protocol: Or converting network protocol
addresses to 48.bit Ethernet address for transmission on Ethernet
hardware, Plummer D., 1982/11/01 (10pp) (.txt=21556) (STD-37) (ARP)
clicking on the ".txt" field retrieves the actual RFC.
also see ARP references in:
1122 S
Requirements for Internet hosts - communication layers, Braden R.,
1989/10/01 (116pp) (.txt=289148) (STD-3) (Ref'ed By 2988)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Secure OS Thoughts
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt
Date: Sat, 30 Aug 2003 01:00:38 GMT
mbealby@myrealbox.com (Martin Bealby) writes:
Objective:
To create a secure operating system suitable for use in highly
security concious environments, with minimal risk of unauthorised
access. Security is paramount, above all the system should be secure,
even if this means a sacrafice in speed.
[To quote Schneier: "We already have enough fast, insecure systems. We
don't need another one."]
some related:
http://www.garlic.com/~lynn/2003j.html#4 A Dark Day
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
slightly related:
http://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
http://www.garlic.com/~lynn/2001m.html#15 departmental servers
http://www.garlic.com/~lynn/2002p.html#6 unix permissions
http://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
EROS: The Extremely Reliable Operating System
http://www.eros-os.org/
and semi-related from eros discussion ...
http://eros.cs.jhu.edu/~shap/NT-EAL4.html
gnosis was the predecessor to keykos, and eros page lists keykos as
the predecessor to eros; misc gnosis/keykos references:
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001n.html#10 TSS/360
http://www.garlic.com/~lynn/2002f.html#59 Blade architectures
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
http://www.garlic.com/~lynn/2003j.html#20 A Dark Day
http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Secure OS Thoughts
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt
Date: Sat, 30 Aug 2003 03:52:51 GMT
dsr writes:
You could use google to search for terms such as "red black" emission
security etc. pretty much SOP for sensitive installations.
merged security glossary at:
http://www.garlic.com/~lynn/secure.htm
sources listed at
http://www.garlic.com/~lynn/index.html#glosnote
from above:
Security: Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site),
CIAO, FCv1, FIPS140, IATF V3 (IATF site), IEEE610, ITSEC, Intel,
JTC1/SC27 (sc27 site), KeyAll, MSC, NIST 800-37, NCSC/TG004, NIAP, NSA
Intrusion, NSTISSC/CNSS, online security study, RFC1983, RFC2504,
RFC2647, RFC2828, TCSEC, TDI, TNI, and misc. Updated 20021108 with
terms from CIAO. Updated 20021205 with terms from 800-37 glossary.
some random information assurance references
http://www.sharp-ideas.net/ia/information_assurance.htm
http://www.thei3p.org/
http://www.thei3p.org/documents/analyses/Context_and_Pervasive_Issues_V1.0s.pdf
http://www.commoncriteria.org/
http://csrc.nist.gov/sec-cert/
http://www.nstissc.gov/html/library.html
http://www2.ni.din.de/sixcms/list.php?page=nani_redirect&alias=sc27
http://www.iatf.net/
http://www.ciao.gov/
http://niap.nist.gov/
http://csrc.nist.gov/publications/drafts.html
http://csrc.ncsl.nist.gov/publications/nistpubs/800-7/node276.html
http://www.nsa.gov/selinux/
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Secure OS Thoughts
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 31 Aug 2003 15:12:07 GMT
"Douglas A. Gwyn" writes:
Your list was well-intentioned, but neither necessary
nor sufficient to obtain a high level of security, and
it would all be subverted anyway in practice. What is
truly needed is a nonsubvertible underlying mechanism.
Capas (all the way down to instruction level) perhaps.
The IBM System/38 was an interesting experiment that
got some of the basics right, but it had no effect on
the design of current sstems.
the folklore is that s/38 was born out of the canceled FS (future
system) project ... multiple past post on FS:
http://www.garlic.com/~lynn/submain.html#futuresys
the follow-on to s/38 was the as/400 ... built on a cisc architecture.
as/400 was moved to power/pc platform in the early 90s ... and still
sells quite a number of power/pc boxes (along with apple, aix, and
linux). misc. search engine results on os/400
http://www.as400guy.com/
http://www.common.org/
http://search400.techtarget.com/home/0,289692,sid3,00.html
http://search400.techtarget.com/featuredTopic/0,290042,sid3_gci921689,00.html
http://www-912.ibm.com/
http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/iSeries/
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Secure OS Thoughts
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 31 Aug 2003 16:56:08 GMT
Anne & Lynn Wheeler writes:
gnosis was the predecessor to keykos, and eros page lists keykos as
the predecessor to eros; misc gnosis/keykos references:
and two specific gnosis/keykos sites:
http://www.cis.upenn.edu/~KeyKOS/
http://www.agorics.com/Library/keykosindex.html
some number of other papers at the same web site:
http://www.agorics.com/library.html
in the late '60s there was some fundamental requirement for security
at the major commercial time-sharing service bureaus. They had
commercial customers ... and there were issues like protecting clients
sensitive corporate information from other each other (as well as
protecting the service from the clients).
in the late '60s there were two time-sharing service bureaus running
CP/67 (IDC and NCSS) and by the early '70s ... they and Tymshare were
offering virtual machine based commercial time-sharing service running
on IBM 370 mainframe computers (based on IBM's standard virtual
machine operating system product).
Gnosis/keykos referenced in previous post:
http://www.garlic.com/~lynn/2003l.html#19 Seucre OS Thoughts
Tymshare originated the Gnosis operating system effort in the '70s for
IBM 370 mainframe to meet generalized commercial time-sharing service
bureau requirements.
some of the earlier papers on security (copied from the above
referenced agoric web page):
GNOSIS - A Prototype Operating System for the 1990's
Provides a general introduction to some of the ideas in KeyKOS. This
paper was presented at an IBM SHARE conference 52 in Chicago in 1979.
Note on the Confinement Problem (1973)
An early statement by Bulter Lampson of security problems as yet
unsolved by modern Operating Systems. Confinement is one of the
features of KeyKOS.
The Confused Deputy (1988)
A paper that explains the limitations of access control systems in
many modern systems and explores how capabilities solve these
problems.
Security in a Secure Capability-Based System (1989)
This Operating Systems Review note corrects some misunderstandings
about security requirements and capability-based systems.
A Note on "Protection Imperfect" (1988)
This Operating Systems Review note corrects a common misunderstaning
about security requirements.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Why more than 1 hole in FW for IPSec
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why more than 1 hole in FW for IPSec
Newsgroups: comp.dcom.vpn,comp.os.linux.networking,comp.os.linux.security
Date: Sun, 31 Aug 2003 19:10:38 GMT
stephen@dino.dnsalias.com (Stephen J. Bevan) writes:
BTW it is not that I think IKE+IPsec is perfect by any means, it is
just that it isn't clear to me that any of the alternative are better.
ipsec had been in progress for some time and not making much headway.
vpn/firewall was introduced in router/gateway working group the fall
94 ietf meeting (san jose?). it caused somewhat of a problem with the
ipsec group .... as well as some router vendors that didn't have
processors with sufficient processing power to do the crypto
operations. There were some number of VPN vaporware products announced
following that meeting. Eventually most vendors introduced
sufficiently powerful processors to perform various firewall and vpn
crypto operations ... and some progress got made. The ipsec group also
somewhat accomodated VPN by referring to it as "lightweight" ipsec
(while the original, end-to-end ipsec got to be called heavyweight
ipsec).
the ssl introduction by netscape ... basically an "end-to-end"
(heavyweight ipsec) transport layer service ... was done in the
application layer (browser and server) since real heavyweight ipsec
was taking so very long.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
RSA vs AES
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Sun, 31 Aug 2003 20:57:16 GMT
George Ou writes:
As for this quote.
"2. Common Root certificate shared across millions of keys. The
obvious think here is that the certificate, once broken, can be used
to fabricate the identity of any one of the millions of people under
the Common Root."
He's got that half right. Root CAs are not shared across keys. They
are pre-distributed in everyone's CTLs (Certificate Trust Lists). If
you manage to break the private key of the root CA, you can indeed
forge identities of anyone, but once it is discovered that forged
identities are being used the Root CA will immediately be revoked out
of the CTL. You would be assuming it would be very easy to "break" a
that is assuming that you are dealing with a public key infrastructure
... where all possible relying parties have a mechanism for
recognising revokation. Lets say that there are 100 million copies of
browsers out there ... that have root CA keys installed. How often do
those browsers check for revoked root CA keys? Every instance of a
browser with installed root CA keys are relying parties for which
there has been a trust relationship created between the relying party
(the browswers) and the CA operations that have their root CA keys
installed.
another scenario raised in similar threads is somebody buys one of the
root CA operations (that have root CA keys installed in common
browsers).
the scenario from ten years ago would be that possibly once a day
there would be a CRL (certificate revokation list) distributed to each
of the (100 million?) relying parties (browsers). Each relying party
(100 million browsers in the world) would perform their daily update
of the list of revoked certificates (either root CA keys and/or just
straight identity specific keys). For high risk items, maybe there
would be an updated CRL sent out every hour to all 100 million
possible relying parties.
misc. past discussions of SSL certificate-based infrastructure:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
IBM Manuals from the 1940's and 1950's
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sun, 31 Aug 2003 22:17:43 GMT
"John W. Kennedy" writes:
Doesn't anyone remember the spec sheet for the System/360 Model 69 anymore?
I don't know about 360/69 ... but the original module numbers were
360/30, 360/40, 360/50, 360/60, 360/62 (360/60 with virtual memory
address relocation hardeware), 360/70.
The 360/60, 360/62, and 360/70 were to have 1mic memory. Somewhere
along the line, 750ns memory came about and the 60, 62, and 70 were
replaced/upgraded to 360/65, 360/67, and 360/75.
Somewhere, I still have a "blue card" for the 360/67. misc. past
posts ref. 360/67 blue card
http://www.garlic.com/~lynn/99.html#11 Old Computers
http://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?
http://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
http://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
http://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Secure OS Thoughts
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers,alt.os.multics
Date: Sun, 31 Aug 2003 22:39:06 GMT
Tom Van Vleck writes:
What I can't determine from the KeyKOS sites is how many
sites actually ran KeyKOS in production. When I interviewed
there in the 80s, I think they said there were some..
the following taken from:
http://www.agorics.com/Library/keykosindex.html
This documentation describes the design and implementation of the
KeyKOS system. Initially developed at Tymshare, Inc., it was deployed
in production in 1981 as a secure server processing credit card
transactions while simultaneously supporting other
applications. Agorics has licensed this system and the associated
patents, and utilizes the fundamental ideas and technology in our
ebusiness solutions.
production use for credit card transactions in 1981 .... it isn't
clear whether than would have been on a "bare" 370 .... or running
under VM in a virtual machine.
In 1985, M/D bought Tymshare and spun off a number of things ...
Tymnet went to B/T(?). I was brought in to perform due diligence on
gnosis before it was spun off to key Logic (and became KeyKOS). I
still have some gnosis hardcopy.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
RSA vs AES
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Sun, 31 Aug 2003 23:34:50 GMT
George Ou writes:
In the case of a simple stolen MS code signing certificate from
Verisign, MS took the extra burden of issuing a critical patch to
revoke that stolen cert. What do you think would happen if one of
Verisign's root CA private key's were somehow miraculously
compromised? Don't you think it would be all over the news? Would
you be so foolish to think the security or PKI industry would simply
rely on people checking the CRLs? No way! It would be all over the
news and just about every security site would be telling you to revoke
those stolen root CAs. MS would issue a patch for all windows OSes.
It would be the biggest news item for weeks to come! Verisign would
loose all credibility and the PR disaster could kill Verisign. It
would be 1000 times more damaging than that stolen MS code signing
cert!
the small caveate is that browsers have easily some fifty pre-loaded
root CA keys .... in some cases for companies that may no longer be in
business. It isn't clear how long it would take for anyone to notice
if any of these other keys ever got compromised ... or even if
somebody questionable bought all the corporate assets at a fire sale.
in the existing ssl browser scenario there is no differentiation regarding
trust levels for preloaded root CA keys.
some old threads about what root CA keys may actually be preloaded
into browsers:
http://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates
netscape 7.1 & mozilla 1.4 cerificate managers don't allow cut & past
.... so the hard way (following organizations have one or more public
keys preloaded, list of public keys for 7.1 & 1.4 are the same):
Keywitness Canada Inc
ABA ECOM, Inc
AOL, Time Warner Inc
AT&T
AddTrust AB
American Online, Inc
American Express Company, Inc
BBN Certificate Services
Baltimore
BetSign NV
Canada Post Corporation
CertSign Certicadora
CyberTrust Japan
Deutsche Telecom AG
Digital Signature Trust
E-Certify
Entrust.net
Equifax
Equifax Secure
Equifax Secure Inc
GTE CyberTrust
GeoTrust Inc
GlobalSign nv-sa
IBM World Registry
Integrion Financial Network
MCI
RSA Data Security
RSA Security
TC TrustCenter for Security In Data Networks
Thawte
Thawte Consulting
Thawte Consulting cc
The USERTRUST Network
USPS
Uptime Group
VISA
ValiCert
VeriSign Trust Network
VeriSign, Inc
Xcert EZ
beTRUSTed
gc
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
RSA vs AES
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Sun, 31 Aug 2003 23:58:48 GMT
... also the M/S case was an key that should have not had been issued
and therefor the process was to distribute an update to ignore the
erroneous key (since there is no real PKI and/or CRL in operation).
while it would also be possible to do something similar if a real key
was compromised .... the resulting problem is that all things that
might have depended on the real key ... now stop working. An update
would be required to both ignore the compromised key as well as load a
new valid key. This would need to get out to the 100 million or so
browsers. Then the ten million or so servers with SSL certificates ...
might have to all get new certificates created and installed.
Public key operation does greatly simplify key distribution issues
compared to secret/symmetric key paradigms. However, some of the
claims made for PKIs in the '90s were still pretty wide of the mark.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Offshore IT
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Offshore IT
Newsgroups: alt.folklore.computers
Date: Mon, 01 Sep 2003 05:09:15 GMT
somewhat topic drift:
http://www.kansascity.com/mld/kansascity/business/6656322.htm?template=contentModules/printstory.jsp
Toyota poised to become top car seller in U.S.
random past threads ... somewhat related:
http://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2003i.html#61 TGV in the USA?
http://www.garlic.com/~lynn/2003i.html#65 TGV in the USA?
misc references to IT:
http://www.informationweek.com/story/IWK20020531S0008
http://www.informationweek.com/story/showArticle.jhtml?articleID=8700345
http://www.eweek.com/article2/0,3959,1133176,00.asp
http://www.forbes.com/best/2002/1007/002.html
http://www.informationweek.com/story/showArticle.jhtml?articleID=6502198
--
Anne & Lynn Wheeler - http://www.garlic.com/~lynn/
Secure OS Thoughts
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 01 Sep 2003 14:07:49 GMT
"Douglas A. Gwyn" writes:
I always thought that it was a realization of Myer's SWARD
architecture.
tss/360 had effectively one level store and other things for the
360/67 (360/65 with virtual memory). it was a fairly large project
(had some 1200 people or so working on it at the peak), announced and
early versions delivered to customers. It never really took off and
was canceled. cp/67 (from the cambridge scientific center with virtual
machine support) and MTS (michigan terminal system) were also
developed for 360/67 using virtual memory. some of the cambridge science
center references:
http://www.garlic.com/~lynn/subtopic.html#545tech
there was some hope that the 360/67 would have "won" the multics bid
... but didn't. some amount of the early ctss, multics, cp/67 history
(both multics and cambridge science center were located at 545 tech
sq). lots of early details can also be found in Melinda's paper:
http://www.princeton.edu/~melinda/
FS (future system) was an extremely aggresive project that possible
peaked at 2500 people ... that was in part was in response to plug
compatible controllers .... something that I've been blamed for help
originating when I was an undergraduate
http://www.garlic.com/~lynn/subtopic.html#360pcm
some specific Future System excerpts/references:
http://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
including discussion at:
http://www.ecole.org/2/CM200195-ENG.pdf
and some discussion from the System R reunion (see "FS" in index):
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Index.html
minor reference:
http://www.cs.clemson.edu/~mark/acs_people.html
Future System was canceled before even being announced.
The lore is that several of the people that worked on FS migrated out
to rochester and did S/38.
some s/38 and as/400 history at:
http://www.400times.co.uk/FrameData/history_of_the_38.htm
from the above:
On the large mainframe front, IBM had just canceled a project known as
FS (Future Systems) that was going be a revolutionary replacement for
the existing line of IBM mainframe computers. After several years of
work, meetings, and more task force meetings and many train loads of
paper specifications later the IBM management team determined the
project was too ambitious even for IBM and IBM abandoned the project
in 1975. (Does any one know the date this is a guess.)?
In the heart of the cornfields in Rochester, Minnesota the S/3 and its
follow on systems S/32 and S/34 were nearing the end of a very
successful life. The time for a replacement system was nearing. There
was no hardware clone of the S/34 but the fear of a clone vendor
replacing existing hardware was high on IBM managements concerns. The
news of FS demise was slow to reach Rochester so the group of
planners, engineers and programmers continued on an independent
approach to design the system for the future at least for the small
and medium business customer. Every one wanted bigger, better, faster,
and cheaper than the now aging S/34 but just how that would be
accomplished was still an unknown.
Early in 1975, I joined the core group of less than 25 people who were
developing the vision of the replacement for S/34. This small group of
talented people with came from varied backgrounds. Some from the
design teams of the S/3, S/32 and S/34 while others had large S/360
and S/370 backgrounds.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
IBM Manuals from the 1940's and 1950's
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 01 Sep 2003 17:52:02 GMT
"John W. Kennedy" writes:
Unfortunately, I can't put my hands on my copy of the special
anniversary edition of IBM JRD, but I rather thought the semiconductor
key store was unique to the 95. The 370/145 was, of course, the firs
IBM production system with semiconductor main RAM. (But it waited a
long time. I saw, at Poughkeepsie, the unique 360/145 prototype.)
somewhere along the way, I dumped 20 years of system journal and
JRD. however, the journal home page is
http://www.research.ibm.com/journal
preface to the anniversary edition:
http://domino.research.ibm.com/tchjr/journalindex.nsf/f29b56f24a66cd0d8525681e007222fb/575145590bc3956a85256bfa0067f4d4?OpenDocumen
Padegs "System 360 and Beyond" from the anniversary edition:
http://domino.research.ibm.com/tchjr/journalindex.nsf/f29b56f24a66cd0d8525681e007222fb/575145590bc3956a85256bfa0067f4d4?OpenDocumen
the actual PDF file:
http://www.research.ibm.com/journal/rd/255/ibmrd2505D.pdf
Table 1 in the above gives model characteristics
Table 2 Announcement and shipment dates.
Model Announced First shipped
System/360
22 71-4-7 71-6
25 68-1-3 68-10
30 64-4-7 65-6
40 64-4-7 65-4
44 65-8-16 66-9
50 64-4-7 65-8
60 64-4-7 not shipped*1
62 64-4-7 not shipped*
65 65-4-22 65-11
67 65-8-16 66-5
70 64-4-7 not shipped*2
75 65-4-22 66-1
85 68-1-30 69-12
91 64-11-17 67-10
92 64-8-17 not shipped*3
95 68-2
195 69-8-20 71-3
System/370
115 73-3-13 74-3
115-2 75-11-10 76-4
125 72-10-4 73-4
125-2 75-11-10 76-2
135 71-3-8 72-4
135-3 76-6-30 77-2
138 76-6-30 76-1I
145 70-9-23 71-6
145-3 76-6-30 77-5
148 76-6-30 77-I
155 70-6-30 73-4
158 72-8-2 71-1
158-3 75-3-25 76-9
165 70-6-30 71-4
168 72-8-2 73-5
168-3 75-3-25 76-6
195 71-6-24 73-8
System/370-compatible
3031 77-10-6 78-3
3032 77-10-6 78-3
3033 77-3-25 78-3
3033-N 79-11-1 80-1
3033-S 80-11-12
3081 80-11-12
4331-1 79-1-30 79-3
4331-2 80-5-7 80-8
4341-1 79-1-30 79-I1
4341-2 80-9-15
1 Replaced by Model 65
2 Replaced by Model 75
3 designated as Model 91
there is also
"amdahl" 360 article in jan/march 2000 RJD
http://domino.research.ibm.com/tchjr/journalindex.nsf/f29b56f24a66cd0d8525681e007222fb/575145590bc3956a85256bfa0067f4d4?OpenDocumen
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
RSA vs AES
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Mon, 01 Sep 2003 19:45:25 GMT
George Ou writes:
Like I said, It isn't a perfect system and it could definitely be
improved. My point is, that points out a flawed PKI implementation
with a poorly designed CRL system. My only point is that one
shouldn't just cavalierly say that PKI/PKC is fundamentally weak.
my issues have been that while asymmetric keys are technologies
.... which offer some interesting advantages compared to symmetric
keys .... fundamentally public and private keys, identity
certificates, PKIs, CRLs, etc are all business processes.
Certificates are a form of credentials ... analogous to the plastic
credit cards (before magstripes) and online POS terminals, or letters
of credit in the days of sailing ships; basically originally targeted
at an offline email environment (aka dial-up the local mail office,
exchange email, hangup, process email).
The issue was that the certificates/credentials are business processes
that substitute for having direct access to the actual certification
authority because of a fragmented, disconnected and/or offline
environment aka CAs are "certification authorities" ... but don't
actually tend to be the authoritative agency for the information being
certified, the CA business tends to involve verifying with the
authoritative agency for the information being verified ... and then
generating a certificate representing that business verification
process. The certificate are stale, static representation of some
business process.
Many of the CA/PKI business weaknesses are recognized as stale, static
representation of information because the target environment is
presumed to be offline and the target infrastructure isn't able to
support online, timely, dynamic operation.
Given that you know that you haven't the capability of doing real
online, timely and dynamic operation .... then the compromise is a
CA/PKI for a disconnected, offline environment against not having
access to any information (aka a stale, static certificate being
considered better alternative to nothing at all).
This is the scenario of the letters of credit from the sailing ship
days ... when remote financial infrastructures (relying parties) had
no online connectivity alternative to the authoritative agency (aka
financial institution issuing the letter of credit). It is also the
pre-1970s scenario of the plastic cards in wallets before online
access to timely, dynamic information became available (in some sense
the financial PKIs of the 1990s were an attempt to roll back the
technology clock for financial institutions to pre-1970 and the age of
strictly offline operation).
There are significant CA/PKI business process deficiencies of stale,
static operation when compared to modern business process with timely,
dynamic operation. However the CA/PKI business process has several
advantages for orignal offline, disconnected design point with stale,
static operation when compared to an alternative of nothing at all.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
RSA vs AES
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Mon, 01 Sep 2003 22:27:10 GMT
George Ou writes:
I think your somewhat trivializing the concept of PKI and PKC by
comparing it to the "letter's of credit" in old sailing days. If
those "letter's of credit" had the unique property of being tamper
resistant and forge proof short of someone stealing well protected
private keys, then you could make that comparison. To make the
comparison in light of that fact is utterly insane and disingenuous.
It is disrespectful to the most significant discovery in cryptography
in thousands of years.
as i said at the start of the previous post .... asymmetric
cryptography is technology .... certificates are business
processes. they are analogous to the offline, stale, static letters of
credit business process (independent of the technology used to make
them tamper resistent).
let's say i have a letter of credit that says that I've got one
million dollars in the bank ... written a year ago and absolutely
tamper resistant. It is now a year later .... from a business process
standpoint ... the letter of credit could be perfectly valid ... and
still be incorrect.
for anything of importance ... given equal opportunity for timely,
dynamic, online reference and stale, static, offline reference ...
whether it refers to how much money i have in an account, whether i
have an account at all, whether I'm an employee; all other things
being equal, which would a business operation prefer:
1) timely, dynamic, online
2) stale, static, offline
the issue wasn't with regard to how great the tamper resistant
characteristics were (aka asymmetric cryptography technology)
... and/or how easily things could be counterfeited .... from a
business process perspective, it was given equal choice between
timely, dynamic, and online vis-a-vis stale, static, and offline
.... which would a business process prefer?
My assertion has been that given equal choice between timely, dynamic,
and online or stale, static, and offline .... a business operation
would always choose timely, dynamic, and online for anything of value
(but might choose stale, static, and offline for things of no value).
Another observation about x.509 identity certificates from the early
'90s, it was quickly determined that overloaded an identity
certificate with lots of privacy and identification information (in
part because it wasn't clear what future relying parties might
require) represented significant privacy and liability exposures
.... especially with the assumption that such certificates would be
indiscriminately spread all over the world. As a result, you somewhat
saw financial institutions in the mid-90s retrenching to
relying-party-only certificates containing only an account number
and the public key. However, it was trivial to show for
relying-party-only certificates that they were redundant and
superfluous in financial settings.
http://www.garlic.com/~lynn/subpubkey.html#rpo
Don't confuse my characterization of CAs and PKIs as a business
process producing stale, static information for offline environments
with anything about the strengths and advantages of using asymmetric
cryptography. I don't believe the criticism of business processeses
relying on stale, static information designed for offline paradigms
(when they have alternatives for dynamic, timely information in an
ubiquitous online environment) in any reflects on the technology used
to make the stale, static information resistant to tampering.
I strongly believe that asymmetric cryptography can be applied to
ubiquitous online environments without having to resort to business
processes (CAs, PKIs, and certificates) that have a design point
targeted at antiquated, offline, disconnected operations.
For instance, in the financial standards X9A10 working group, the
requirement was for a standard that preserved the integrity of the
financial infrastructure for all electronic retail payments (ALL as in
credit, debit, stored-value, ACH, etc, ... and ALL as in internet,
point-of-sale, face-to-face, automated, non-face-to-face, aka
ALL). The resulting standard, X9.59 demonstrates that asymmetric
cryptography (in the form of digital signatures) can provide very high
integraty level, operating in a dynamic, timely online environment
without resorting to any form of PKI and/or CA business paradigm
(certificate-less):
http://www.garlic.com/~lynn/x959.html#x959
slightly related threads:
http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/aepay11.htm#67 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Thoughts on Utility Computing?
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 02 Sep 2003 18:41:57 GMT
rachess@aol.com (Rachel) writes:
I am doing some research on utility computing and have been coming
across conflicting information from parties I have talked to and
material I have read.
Some sources say utility computing is nothing more than HP & IBM's way
of creating a fad/trend/need that doesn't necessarily exist, basically
because their companies are, relatively speaking, in trouble. Wall St.
Journal reported that SSP (storage providers) are collapsing which has
ramifications on utility adoption. They also cited that large
organizations like Ford are going to create an "internal" utility
model whereby their IT organization will provide the utility situation
as opposed to outsourcing the utility model to a third-party like IBM.
Others say, not only is this the future, but outsourcing to IBM, HP,
is the means since this is core competency for them.
Been seeing activity like tradeshows on utility computing coming up
and more articles as well.
So, I ask the field professionals - what is the deal here? Have you
heard anything within your own organizations about adopting the
utility computing model? Or is this a marketing effort by HP, IBM,
etc. to get more $$$ (fad or reality)? And, if so, will it be an
internal model or an outsourced model? What organizations are likely
to buy into it?
Thanks for your thoughts or observations (in reality)!
is this "utility" as in "on demand" ... or is it "utility" as a
"service" ... and whether or not it is "on demand" or "service"
... does it also imply "out-sourced"?
>From a "service" standpoint ... computing service bureaus have been
around for some time (for instance ibm selling off "service bureau
corporation" to CDC in the early '70s as part of federal
gov. settlement).
Another example is in 1969, Boeing formed BCS and (after some
resistance) moved most of the computing centers and IT organizations
into BCS. The idea was that BCS would be a "utility" and provide
service to both internal organizations as well as be free to offer
services externally. One of the first processors that went into BCS
was a 360/67 running CP/67. This also sort of put BCS into the
category of CP/67 time-sharing service bureau business along with IDC
and NCSS that were also formed to provide commercial CP/67 based
time-sharing services in 68/69.
http://www.garlic.com/~lynn/submain.html#timeshare
The university that I was at in the late '60s did something similar
with its computing center ... although it had to go to the state
legislature to get the necessary legistlative approval.
Part of the issue prior to the separation of computing service and the
rest of the organization ... was that it was hard to value the
computing service. Separating the organizations and creating explicit
charges and book accounting for use and deliverables allowed the
organizations to create value determination for the computing service
(even if the internal corporate accounting was all done with funny
money).
Some amount of the out-sourcing and on-demand, theoritically allows
corporations to move to pay-as-you-go model; they may pay more in
aggregate than compared with an in-house operation ... however there
seem to be some amount of business moving to an immediate cash flow
operation, not being able to bet on what their business and/or data
processing technology will look like in even 18-36 months (eliminating
capital expeditures that may have 2-5 year write-off periods).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
RSA vs AES
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Tue, 02 Sep 2003 21:31:56 GMT
waldyrbenits@ip2.com.br (Waldyr) writes:
Now you perfectly solved my problem, because simply we cannot compare
them.
Thank you very much and sorry for the problem I' ve caused on the web.
there is one reason for comparing them.
Say you have a SSL type system where a symmetric key is used to
protect data, and an asymmetric key is used to protect the symmetric
key.
If there is a requirement for a certain strength symmetric
infrastructure to protect the data (algorithm, keysize, etc) ... then
you also need to know that the asymmetric crypto protection is at
least as strong as the symmetric crypto protection ... or the data
could be vulnerable to attacks on the asymmetric operations ... even
if it wasn't vulnerable to attacks on the symmetric operations.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Proposal for a new PKI model (At least I hope it's new)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Wed, 03 Sep 2003 01:09:40 GMT
"George Ou" writes:
DNS system where you would have a ".com" root CA that would assign
your domain level root CA signing privileges for your domain only?
Then the world would have no problem trusting your domain level PKI
servers for just your domain. That trust is impossible under our
current PKI system because they would have to trust your PKI servers
to sign for everything under the sun. I believe that this lack of
granularity grants an absurd monopoly to companies like Verisign, in
addition to many other problems that make public PKI deployment
pathetic. If a PKI system (like DNS) that delegates signing
authority to the individual domains could be standardized, it would
instantly allow PKI to realize it's original aspirations of vast
global deployment to empower PKC everywhere! Just think, you will
never need to purchase more than one certificate from Verisign for
your entire domain once every 5 years!
I don't know if this concept is new and I can only hope it is, but I
wrote the following original work which I hope you will enjoy
reading.
we were working on this thing with this small client/server startup
that wanted to do payment transactions:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and as part of that had to perform due diligence on all these things
that were supposedly PKI Certification Authorities. As part of that we
coined the term certificate manufacturing to distinquish from actual
PKIs.
it turns out that one of the reasons for the SSL server domain name
certificates was because of perceived issues in the domain name
infrastructure. However, it turns out that the authoritative agency
for domain names is the domain name infrastructure and all the CAs
issuing SSL server domain name certificates have to go to the
authoritative agency for domain names in order to validate the
information for placing in SSL server domain name certificates (the
very same domain name infrastructure that integrity concerns about
gave rise to the need for SSL server domain name certificates)
Now, it so happens that the SSL server domain name certificate
industry is in something of a quandary ... they are dependent on the
domain name infrastructure which has integrity issues that gave rise
to the need for SSL domain name certificates.
So there have been some number of proposals to strengthen the
integrity of the domain name instructure ... somewhat prompted by the
SSL server domain name certificate industry ... so that they can rely
on the integrity of the domain name infrastructure for their purposes.
This creates something of a catch-22 for the SSL server domain name
certificate industry since improving the integrity of the domain name
infrastructure reduces the need for SSL server domain name
certificates (compensating for integrity issues in the domain name
infrastructure).
The other issue is that somewhat from the SSL server domain name
certificate industry, one of the proposals for improving the integrity
of the domain name infrastructure is that public keys be registered at
the same time as domain names are registered. This also represents a
catch-22 for the SSL server domain name certificate industry. If you
have a trusted, timely, dynamic, online information distribution
infrastructure and it also had public keys that were available for
distribution, it would go a long ways towards eliminating all of the
requirement for SSL server domain name certificates.
Rather than having stale, static, SSL server domain name certificates
for being able to validate a server's public key .... the public key
is distributed from the same trusted infrastructure that distributes
the domain name to ip-address information (aka the existing domain
name service implementations are actually able to distribute timely,
dynamic, online information not restricted to ip-addresses).
So the SSL server domain name certificate industry is in a real
catch-22, (effectively sowing the seeds for their own demise) they are
1) proposing that the integrity of the domain name infrastructure be
fixed (so that they can trust it), but that means that everybody could
trust it also, eliminating much of the requirement for SSL domain name
certificates
2) part of the their proposal for improving the integrity of the
domain name infrastructure involves registering public keys when
domain names are registered. However, this sets up an infrastructure
for timely, dynamic, online trusted information distribution of the
public keys (in addition to the trusted distribution of the
ip-address), eliminating the need for stale, static certificate-based
distribution of public keys.
This also opens up the ancillary option of improving the SSL protocol,
the domain name infrastructure can have the public key and the
preferred crypto optionss registered. At the same time the client made
a domain name infrastructure request for an ip-address, the system
could optionally return the associated public key and preferred crypto
options piggybacked in the same transfer. If the client is in
agreement, then it could bypass all the certificate protocol chatter
and just send the initial session key, encrypted with the server's
public key as part of initial contacting the server. Assuming something
like an XTP, 3 packet transaction protocol .... the actual encrypted
session data could ride in the same packet. Assuming everything is
perfectly valid on the server end ... the encrypted response and
session tear-down could come back in the response.
Basically, for on online world, you eliminate the stale, static,
offline PKI paradigm, and move to a modern, timely, dynamic, online
(certificate-less)infrastructure.
lots of past threads regarding the catch-22 for the SSL domain name
server industry sowing the seeds of their own demise:
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1 Domain Name integrity problem
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2 Domain Name integrity problem
http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work?
http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#78 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#79 ssl certs
http://www.garlic.com/~lynn/aepay10.htm#80 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aepay11.htm#43 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
http://www.garlic.com/~lynn/aepay11.htm#45 Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
http://www.garlic.com/~lynn/aepay12.htm#18 DNS inventor says cure to net identity problems is right under our nose
http://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#3 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#8 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki3 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki4 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki12 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm10.htm#cfppki20 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#33 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#0 invoicing with PKI
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2000e.html#47 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001c.html#9 Server authentication
http://www.garlic.com/~lynn/2001c.html#82 ARP timeout?
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001d.html#36 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#27 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#33 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#36 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#37 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#39 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#2 Root certificates
http://www.garlic.com/~lynn/2001g.html#10 Root certificates
http://www.garlic.com/~lynn/2001g.html#16 Root certificates
http://www.garlic.com/~lynn/2001g.html#19 Root certificates
http://www.garlic.com/~lynn/2001g.html#21 Root certificates
http://www.garlic.com/~lynn/2001g.html#55 Using a self-signed certificate on a private network
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#4 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#6 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
http://www.garlic.com/~lynn/2001l.html#26 voice encryption box (STU-III for the masses)
http://www.garlic.com/~lynn/2001l.html#29 voice encryption box (STU-III for the masses)
http://www.garlic.com/~lynn/2001l.html#31 voice encryption box (STU-III for the masses)
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
http://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues in IE and Verisign
http://www.garlic.com/~lynn/2001n.html#73 A PKI question and an answer
http://www.garlic.com/~lynn/2002.html#32 Buffer overflow
http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification
http://www.garlic.com/~lynn/2002g.html#65 Real man-in-the-middle attacks?
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002j.html#61 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002j.html#79 Q: Trust in an X.509 certificate
http://www.garlic.com/~lynn/2002k.html#11 Serious vulnerablity in several common SSL implementations?
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
http://www.garlic.com/~lynn/2002o.html#7 Are ssl certificates all equally secure?
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003.html#52 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003d.html#29 SSL questions
http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Thoughts on Utility Computing?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Sep 2003 04:33:28 GMT
Robert Myers writes:
I'm not entirely certain I know what utility computing is supposed to
do that, say, Boeing Computer Services didn't do, and using BCS did
not mean outsourcing. It meant that most of your hardware and some of
your software were not on site and that you bought the use of hardware
and some software as you needed it. It was clumsy because data
transmission was slow, and it was expensive because data storage costs
were ridiculous.
The data storage problem may still be the killer. Data transmission
is much better than it was in the days of BCS, but it's not so much
better that you can afford to be shipping lots of data back and forth,
and paying someone else for routine storage of your data is
horrifyingly expensive--and a little scary.
But who knows what utility computing really means. If it means having
a computer onsite with processors that you pay for only when you
switch them on, then the data storage and transmission problems go
away, but at that point the whole concept feels a little desperate,
more like a marketing and pricing gimmick than anything else.
the on demand scenario may just mean a little more like the old days
of leasing ... but with less up front commitment or like the tv adds
for some of the long distance and mobile phone services ... you only
pay for what you use when you use it ... and no upfront contract
and/or commitment.
one of the processor economics seems to be extremely high upfront
costs for development ... but with volume manufacturing ... relatively
small incremental manufacturing costs per processor. Throwing in
double the processors per box ... and the customer only turns extras
on for peak processing ... may represent an attractive economic
prospect.
The customer may find that they can gracefully grow into the extra
capacity w/o huge incremental cost justifications for capital
equipment. In some cases processor decisions were so significant that
they only got made as part of yearly budget cycle. There can also be
some chicken and egg ... can't justify the extra for large capital
equipment w/o finer granularity of growth (and can't demonstrate
growth w/o additional capacity). The customer tries out the extra
capacity on a piece meal basis ... and then more gracely grows into
the extra capacity. This is not so much a marketing/pricing gimmick
.... but a much finer capacity growth management gimmick for the
customer ... aka more of a case of "try it, you may like it"
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Thoughts on Utility Computing?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Sep 2003 13:11:56 GMT
nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
A more realistic scenario is that the extra capacity is used to
provide ample warm spares, thus reducing maintenance costs, and
the extra power for peak loading is a bonus. Given the way that
IBM and other vendors have cut back on their field support staff,
I would place good money on this being the real reason.
it also doesn't require service people to come in and install the
extra capacity.
note however, some of the presentations at SHARE in the '70s on vm/370
was that vm/370 customers had a lot larger computer demand growth
(compared to mvs) ... customers that installed 370/135 initially, grew
faster to multiple 168s. One of the case studies at SHARE was amoco
research in tulsa ... they had an 1800 and installed a 370/135 with vm
... and relatively quickly grew to multiple 168s. One of the SHARE
study issues was trying to determine what factors allowed/accounted
for large increase in computing demand.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Port Assignment- OT in a Small Way
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Port Assignment- OT in a Small Way
Newsgroups: alt.computer.security,alt.hackers.malicious,comp.security.firewalls,comp.security.misc,microsoft.public.security,alt.2600.hackers
Date: Wed, 03 Sep 2003 13:56:07 GMT
Tracker <"snailmail(remove/valid)222000"@yahoo.com> writes:
Copyright 2003 by Debbie X. All rights Reserved. No part of this
publication may be reproduced in any form or by any means, or stored in
a data base or retrieval system, without prior written permission of the
publisher.
I do a simple cross reference when the STD1 portocol name
matches the port number name ... see
http://www.garlic.com/~lynn/rfcietff.htm
"Protocol" in the RFC's listed by section
The official list use to be "Assigned Numbers", RFC 1700
but as of RFC 3232, "Assigned Numbers: RFC 1700 is Replaced by on
On-line Database", they are now just listed in an online file that
gets updated.
The distinction is that RFCs are static documents, that once published
are never changed. To change the contents of an RFC required releasing
a new RFC.
See "Internet Assigned Numbers Authority" at:
http://www.iana.org/
and:
http://www.iana.org/numbers.html
The "Port Numbers" section under:
http://www.iana.org/numbers.html#P
specifically
http://www.iana.org/assignments/port-numbers
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
The real history of computer architecture: the short form
Refed: **, - **, - **, - **, -