307 digit number factored

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored

part of the quick IETF uptake of SSL and VPN in the 94/95 time-frame was that there
really wasn't any serious competition. there was ipsec ... but it was end-to-end implementation
at low level ip-stack ... which were kernel implementations ... and then was faced
with the whole issue of distribution, installation and support of new kernels on
machines all around the world (from a variety of different vendors and different
operating systems).

SSL was almost a no-brainer ... since it just involved loading/installing a new
application (orders of magnitude easier than ipsec). lots of collected posts
mentioning SSL and/or SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

in the same time-frame VPN was introduced at the gateway committee meeting at '94
San Jose IETF meeting. We had worked with the guy on and off since the late 70s and
he originally developed the technology for his own use ... between home and office;
actually both his wife and he worked for different technology companies ... he got
a leased line from the house to his office ... and her company got a circuit from
his office to their office. The issue was how to encrypt the wife's communication w/o
having it exposed to the husband and/or the husband's company.

sort of the state-of-the art had been link encryptors ... for a little topic drift ...
the internal corporate network had been larger than the arpanet/internet from just
about the beginning until possibly summer of '85. the internal network required
encryption on everything leaving the premise ... and in the mid-80s there were 
comments that the internal network had over half of all link encryptors in the world.
misc. past posts mentioning the internal network.
http://www.garlic.com/~lynn/subnetwork.html#internalnet

the requirement that led to VPN was how to carry separately encrypted streams over 
the same link. ipsec would have solved the problem ... but again was end-to-end
solution that required upgrading all the low-level ip-stacks ... which required
distribution, installation (and support) of new kernel. the VPN solution was
to handle the stream encryption/decryption in boundary routers (which could be
tunneled over other infrastructure).

my observation was this resulted in some amount of consternation in the ipsec 
faction ... which they somewhat resolved by starting to refer to VPN as "lightweight
ipsec" (and of course, everybody else could then refer to regular ipsec as
"heavyweight ipsec").

the other problems was with various router vendors in the IETF. it was
sort of divided along the lines of the vendors that had enuf horse power in
their current boxes to implement and deploy VPN support ... and the other vendors
whos' products didn't have enuf processing power available to do the crypto
operations in support of VPN. This difference dragged out some of the VPN standardization
activity within IETF.

misc. past posts mentioning "lightweight ipsec"
http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS
http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec
http://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip

for other drift ... some of the people doing VPN implementations were using RSA
bsafe library ported to whatever processor they were using. Some number of these
put in effort to enhance the performance of bsafe library.

some of this was going on when we were in transition from working on the infrastructure
that is currently frequently referred to as electronic commerce and work in the
x9a10 financial standard committee. in that same time frame there were other
efforts looking at "enhancing" how payment transactions could be implemented and
deployed for the internet (as opposed to x9a10 standards work which had a requirement 
to have a standard that preserved the integrity of financial infrastructure for
ALL retail payments). 

One of these published some of their specification and from the specification I drew 
up a business operation profile and a "public key" operation profile. I then got the 
"public key" operation profile executed on a number of different platforms using the 
"speeded up" bsafe library (running four times faster) ... and reported the numbers 
back to the organization responsible for that specification. The people in the organization
"claimed" that the performance numbers were one hundred times too slow (instead of
observing that they were four times too fast). About six months later when
they actually had some prototype code ... the "profile" numbers were within a couple
percent of measured (the speeded up bsafe library having been returned to rsa).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com