1 files changed, 0 insertions, 476 deletions

diff --git a/src/lib/libssl/src/MacOS/Randomizer.cpp b/src/lib/libssl/src/MacOS/Randomizer.cpp
deleted file mode 100644
index cceb6bde44..0000000000
--- a/src/lib/libssl/src/MacOS/Randomizer.cpp
+++ /dev/null
@@ -1,476 +0,0 @@
-/* 
-------- Strong random data generation on a Macintosh (pre - OS X) ------
-                
---      GENERAL: We aim to generate unpredictable bits without explicit
-        user interaction. A general review of the problem may be found
-        in RFC 1750, "Randomness Recommendations for Security", and some
-        more discussion, of general and Mac-specific issues has appeared
-        in "Using and Creating Cryptographic- Quality Random Numbers" by
-        Jon Callas (www.merrymeet.com/jon/usingrandom.html).
-
-        The data and entropy estimates provided below are based on my
-        limited experimentation and estimates, rather than by any
-        rigorous study, and the entropy estimates tend to be optimistic.
-        They should not be considered absolute.
-
-        Some of the information being collected may be correlated in
-        subtle ways. That includes mouse positions, timings, and disk
-        size measurements. Some obvious correlations will be eliminated
-        by the programmer, but other, weaker ones may remain. The
-        reliability of the code depends on such correlations being
-        poorly understood, both by us and by potential interceptors.
-
-        This package has been planned to be used with OpenSSL, v. 0.9.5.
-        It requires the OpenSSL function RAND_add. 
-
---      OTHER WORK: Some source code and other details have been
-        published elsewhere, but I haven't found any to be satisfactory
-        for the Mac per se:
-
-        * The Linux random number generator (by Theodore Ts'o, in
-          drivers/char/random.c), is a carefully designed open-source
-          crypto random number package. It collects data from a variety
-          of sources, including mouse, keyboard and other interrupts.
-          One nice feature is that it explicitly estimates the entropy
-          of the data it collects. Some of its features (e.g. interrupt
-          timing) cannot be reliably exported to the Mac without using
-          undocumented APIs.
-
-        * Truerand by Don P. Mitchell and Matt Blaze uses variations
-          between different timing mechanisms on the same system. This
-          has not been tested on the Mac, but requires preemptive
-          multitasking, and is hardware-dependent, and can't be relied
-          on to work well if only one oscillator is present.
-
-        * Cryptlib's RNG for the Mac (RNDMAC.C by Peter Gutmann),
-          gathers a lot of information about the machine and system
-          environment. Unfortunately, much of it is constant from one
-          startup to the next. In other words, the random seed could be
-          the same from one day to the next. Some of the APIs are
-          hardware-dependent, and not all are compatible with Carbon (OS
-          X). Incidentally, the EGD library is based on the UNIX entropy
-          gathering methods in cryptlib, and isn't suitable for MacOS
-          either.
-
-        * Mozilla (and perhaps earlier versions of Netscape) uses the
-          time of day (in seconds) and an uninitialized local variable
-          to seed the random number generator. The time of day is known
-          to an outside interceptor (to within the accuracy of the
-          system clock). The uninitialized variable could easily be
-          identical between subsequent launches of an application, if it
-          is reached through the same path.
-
-        * OpenSSL provides the function RAND_screen(), by G. van
-          Oosten, which hashes the contents of the screen to generate a
-          seed. This is not useful for an extension or for an
-          application which launches at startup time, since the screen
-          is likely to look identical from one launch to the next. This
-          method is also rather slow.
-
-        * Using variations in disk drive seek times has been proposed
-          (Davis, Ihaka and Fenstermacher, world.std.com/~dtd/;
-          Jakobsson, Shriver, Hillyer and Juels,
-          www.bell-labs.com/user/shriver/random.html). These variations
-          appear to be due to air turbulence inside the disk drive
-          mechanism, and are very strongly unpredictable. Unfortunately
-          this technique is slow, and some implementations of it may be
-          patented (see Shriver's page above.) It of course cannot be
-          used with a RAM disk.
-
---      TIMING: On the 601 PowerPC the time base register is guaranteed
-        to change at least once every 10 addi instructions, i.e. 10
-        cycles. On a 60 MHz machine (slowest PowerPC) this translates to
-        a resolution of 1/6 usec. Newer machines seem to be using a 10
-        cycle resolution as well.
-        
-        For 68K Macs, the Microseconds() call may be used. See Develop
-        issue 29 on the Apple developer site
-        (developer.apple.com/dev/techsupport/develop/issue29/minow.html)
-        for information on its accuracy and resolution. The code below
-        has been tested only on PowerPC based machines.
-
-        The time from machine startup to the launch of an application in
-        the startup folder has a variance of about 1.6 msec on a new G4
-        machine with a defragmented and optimized disk, most extensions
-        off and no icons on the desktop. This can be reasonably taken as
-        a lower bound on the variance. Most of this variation is likely
-        due to disk seek time variability. The distribution of startup
-        times is probably not entirely even or uncorrelated. This needs
-        to be investigated, but I am guessing that it not a majpor
-        problem. Entropy = log2 (1600/0.166) ~= 13 bits on a 60 MHz
-        machine, ~16 bits for a 450 MHz machine.
-
-        User-launched application startup times will have a variance of
-        a second or more relative to machine startup time. Entropy >~22
-        bits.
-
-        Machine startup time is available with a 1-second resolution. It
-        is predictable to no better a minute or two, in the case of
-        people who show up punctually to work at the same time and
-        immediately start their computer. Using the scheduled startup
-        feature (when available) will cause the machine to start up at
-        the same time every day, making the value predictable. Entropy
-        >~7 bits, or 0 bits with scheduled startup.
-
-        The time of day is of course known to an outsider and thus has 0
-        entropy if the system clock is regularly calibrated.
-
---      KEY TIMING: A  very fast typist (120 wpm) will have a typical
-        inter-key timing interval of 100 msec. We can assume a variance
-        of no less than 2 msec -- maybe. Do good typists have a constant
-        rhythm, like drummers? Since what we measure is not the
-        key-generated interrupt but the time at which the key event was
-        taken off the event queue, our resolution is roughly the time
-        between process switches, at best 1 tick (17 msec). I  therefore
-        consider this technique questionable and not very useful for
-        obtaining high entropy data on the Mac.
-
---      MOUSE POSITION AND TIMING: The high bits of the mouse position
-        are far from arbitrary, since the mouse tends to stay in a few
-        limited areas of the screen. I am guessing that the position of
-        the mouse is arbitrary within a 6 pixel square. Since the mouse
-        stays still for long periods of time, it should be sampled only
-        after it was moved, to avoid correlated data. This gives an
-        entropy of log2(6*6) ~= 5 bits per measurement.
-
-        The time during which the mouse stays still can vary from zero
-        to, say, 5 seconds (occasionally longer). If the still time is
-        measured by sampling the mouse during null events, and null
-        events are received once per tick, its resolution is 1/60th of a
-        second, giving an entropy of log2 (60*5) ~= 8 bits per
-        measurement. Since the distribution of still times is uneven,
-        this estimate is on the high side.
-
-        For simplicity and compatibility across system versions, the
-        mouse is to be sampled explicitly (e.g. in the event loop),
-        rather than in a time manager task.
-
---      STARTUP DISK TOTAL FILE SIZE: Varies typically by at least 20k
-        from one startup to the next, with 'minimal' computer use. Won't
-        vary at all if machine is started again immediately after
-        startup (unless virtual memory is on), but any application which
-        uses the web and caches information to disk is likely to cause
-        this much variation or more. The variation is probably not
-        random, but I don't know in what way. File sizes tend to be
-        divisible by 4 bytes since file format fields are often
-        long-aligned. Entropy > log2 (20000/4) ~= 12 bits.
-        
---      STARTUP DISK FIRST AVAILABLE ALLOCATION BLOCK: As the volume
-        gets fragmented this could be anywhere in principle. In a
-        perfectly unfragmented volume this will be strongly correlated
-        with the total file size on the disk. With more fragmentation
-        comes less certainty. I took the variation in this value to be
-        1/8 of the total file size on the volume.
-
---      SYSTEM REQUIREMENTS: The code here requires System 7.0 and above
-        (for Gestalt and Microseconds calls). All the calls used are
-        Carbon-compatible.
-*/
-
-/*------------------------------ Includes ----------------------------*/
-
-#include "Randomizer.h"
-
-// Mac OS API
-#include <Files.h>
-#include <Folders.h>
-#include <Events.h>
-#include <Processes.h>
-#include <Gestalt.h>
-#include <Resources.h>
-#include <LowMem.h>
-
-// Standard C library
-#include <stdlib.h>
-#include <math.h>
-
-/*---------------------- Function declarations -----------------------*/
-
-// declared in OpenSSL/crypto/rand/rand.h
-extern "C" void RAND_add (const void *buf, int num, double entropy);
-
-unsigned long GetPPCTimer (bool is601); // Make it global if needed
-                                        // elsewhere
-
-/*---------------------------- Constants -----------------------------*/
-
-#define kMouseResolution 6              // Mouse position has to differ
-                                        // from the last one by this
-                                        // much to be entered
-#define kMousePositionEntropy 5.16      // log2 (kMouseResolution**2)
-#define kTypicalMouseIdleTicks 300.0    // I am guessing that a typical
-                                        // amount of time between mouse
-                                        // moves is 5 seconds
-#define kVolumeBytesEntropy 12.0        // about log2 (20000/4),
-                                        // assuming a variation of 20K
-                                        // in total file size and
-                                        // long-aligned file formats.
-#define kApplicationUpTimeEntropy 6.0   // Variance > 1 second, uptime
-                                        // in ticks  
-#define kSysStartupEntropy 7.0          // Entropy for machine startup
-                                        // time
-
-
-/*------------------------ Function definitions ----------------------*/
-
-CRandomizer::CRandomizer (void)
-{
-        long    result;
-        
-        mSupportsLargeVolumes =
-                (Gestalt(gestaltFSAttr, &result) == noErr) &&
-                ((result & (1L << gestaltFSSupports2TBVols)) != 0);
-        
-        if (Gestalt (gestaltNativeCPUtype, &result) != noErr)
-        {
-                mIsPowerPC = false;
-                mIs601 = false;
-        }
-        else
-        {
-                mIs601 = (result == gestaltCPU601);
-                mIsPowerPC = (result >= gestaltCPU601);
-        }
-        mLastMouse.h = mLastMouse.v = -10;      // First mouse will
-                                                // always be recorded
-        mLastPeriodicTicks = TickCount();
-        GetTimeBaseResolution ();
-        
-        // Add initial entropy
-        AddTimeSinceMachineStartup ();
-        AddAbsoluteSystemStartupTime ();
-        AddStartupVolumeInfo ();
-        AddFiller ();
-}
-
-void CRandomizer::PeriodicAction (void)
-{
-        AddCurrentMouse ();
-        AddNow (0.0);   // Should have a better entropy estimate here
-        mLastPeriodicTicks = TickCount();
-}
-
-/*------------------------- Private Methods --------------------------*/
-
-void CRandomizer::AddCurrentMouse (void)
-{
-        Point mouseLoc;
-        unsigned long lastCheck;        // Ticks since mouse was last
-                                        // sampled
-
-#if TARGET_API_MAC_CARBON
-        GetGlobalMouse (&mouseLoc);
-#else
-        mouseLoc = LMGetMouseLocation();
-#endif
-        
-        if (labs (mLastMouse.h - mouseLoc.h) > kMouseResolution/2 &&
-            labs (mLastMouse.v - mouseLoc.v) > kMouseResolution/2)
-                AddBytes (&mouseLoc, sizeof (mouseLoc),
-                                kMousePositionEntropy);
-        
-        if (mLastMouse.h == mouseLoc.h && mLastMouse.v == mouseLoc.v)
-                mMouseStill ++;
-        else
-        {
-                double entropy;
-                
-                // Mouse has moved. Add the number of measurements for
-                // which it's been still. If the resolution is too
-                // coarse, assume the entropy is 0.
-
-                lastCheck = TickCount() - mLastPeriodicTicks;
-                if (lastCheck <= 0)
-                        lastCheck = 1;
-                entropy = log2l
-                        (kTypicalMouseIdleTicks/(double)lastCheck);
-                if (entropy < 0.0)
-                        entropy = 0.0;
-                AddBytes (&mMouseStill, sizeof (mMouseStill), entropy);
-                mMouseStill = 0;
-        }
-        mLastMouse = mouseLoc;
-}
-
-void CRandomizer::AddAbsoluteSystemStartupTime (void)
-{
-        unsigned long   now;            // Time in seconds since
-                                        // 1/1/1904
-        GetDateTime (&now);
-        now -= TickCount() / 60;        // Time in ticks since machine
-                                        // startup
-        AddBytes (&now, sizeof (now), kSysStartupEntropy);
-}
-
-void CRandomizer::AddTimeSinceMachineStartup (void)
-{
-        AddNow (1.5);                   // Uncertainty in app startup
-                                        // time is > 1.5 msec (for
-                                        // automated app startup).
-}
-
-void CRandomizer::AddAppRunningTime (void)
-{
-        ProcessSerialNumber PSN;
-        ProcessInfoRec          ProcessInfo;
-        
-        ProcessInfo.processInfoLength = sizeof (ProcessInfoRec);
-        ProcessInfo.processName = nil;
-        ProcessInfo.processAppSpec = nil;
-        
-        GetCurrentProcess (&PSN);
-        GetProcessInformation (&PSN, &ProcessInfo);
-
-        // Now add the amount of time in ticks that the current process
-        // has been active
-
-        AddBytes (&ProcessInfo, sizeof (ProcessInfoRec),
-                        kApplicationUpTimeEntropy);
-}
-
-void CRandomizer::AddStartupVolumeInfo (void)
-{
-        short                   vRefNum;
-        long                    dirID;
-        XVolumeParam    pb;
-        OSErr                   err;
-        
-        if (!mSupportsLargeVolumes)
-                return;
-                
-        FindFolder (kOnSystemDisk, kSystemFolderType, kDontCreateFolder,
-                        &vRefNum, &dirID);
-        pb.ioVRefNum = vRefNum;
-        pb.ioCompletion = 0;
-        pb.ioNamePtr = 0;
-        pb.ioVolIndex = 0;
-        err = PBXGetVolInfoSync (&pb);
-        if (err != noErr)
-                return;
-                
-        // Base the entropy on the amount of space used on the disk and
-        // on the next available allocation block. A lot else might be
-        // unpredictable, so might as well toss the whole block in. See
-        // comments for entropy estimate justifications.
-
-        AddBytes (&pb, sizeof (pb),
-                kVolumeBytesEntropy +
-                log2l (((pb.ioVTotalBytes.hi - pb.ioVFreeBytes.hi)
-                                * 4294967296.0D +
-                        (pb.ioVTotalBytes.lo - pb.ioVFreeBytes.lo))
-                                / pb.ioVAlBlkSiz - 3.0));
-}
-
-/*
-        On a typical startup CRandomizer will come up with about 60
-        bits of good, unpredictable data. Assuming no more input will
-        be available, we'll need some more lower-quality data to give
-        OpenSSL the 128 bits of entropy it desires. AddFiller adds some
-        relatively predictable data into the soup.
-*/
-
-void CRandomizer::AddFiller (void)
-{
-        struct
-        {
-                ProcessSerialNumber psn;        // Front process serial
-                                                // number
-                RGBColor        hiliteRGBValue; // User-selected
-                                                // highlight color
-                long            processCount;   // Number of active
-                                                // processes
-                long            cpuSpeed;       // Processor speed
-                long            totalMemory;    // Total logical memory
-                                                // (incl. virtual one)
-                long            systemVersion;  // OS version
-                short           resFile;        // Current resource file
-        } data;
-        
-        GetNextProcess ((ProcessSerialNumber*) kNoProcess);
-        while (GetNextProcess (&data.psn) == noErr)
-                data.processCount++;
-        GetFrontProcess (&data.psn);
-        LMGetHiliteRGB (&data.hiliteRGBValue);
-        Gestalt (gestaltProcClkSpeed, &data.cpuSpeed);
-        Gestalt (gestaltLogicalRAMSize, &data.totalMemory);
-        Gestalt (gestaltSystemVersion, &data.systemVersion);
-        data.resFile = CurResFile ();
-        
-        // Here we pretend to feed the PRNG completely random data. This
-        // is of course false, as much of the above data is predictable
-        // by an outsider. At this point we don't have any more
-        // randomness to add, but with OpenSSL we must have a 128 bit
-        // seed before we can start. We just add what we can, without a
-        // real entropy estimate, and hope for the best.
-
-        AddBytes (&data, sizeof(data), 8.0 * sizeof(data));
-        AddCurrentMouse ();
-        AddNow (1.0);
-}
-
-//-------------------  LOW LEVEL ---------------------
-
-void CRandomizer::AddBytes (void *data, long size, double entropy)
-{
-        RAND_add (data, size, entropy * 0.125); // Convert entropy bits
-                                                // to bytes
-}
-
-void CRandomizer::AddNow (double millisecondUncertainty)
-{
-        long time = SysTimer();
-        AddBytes (&time, sizeof (time), log2l (millisecondUncertainty *
-                        mTimebaseTicksPerMillisec));
-}
-
-//----------------- TIMING SUPPORT ------------------
-
-void CRandomizer::GetTimeBaseResolution (void)
-{       
-#ifdef __powerc
-        long speed;
-        
-        // gestaltProcClkSpeed available on System 7.5.2 and above
-        if (Gestalt (gestaltProcClkSpeed, &speed) != noErr)
-                // Only PowerPCs running pre-7.5.2 are 60-80 MHz
-                // machines.
-                mTimebaseTicksPerMillisec =  6000.0D;
-        // Assume 10 cycles per clock update, as in 601 spec. Seems true
-        // for later chips as well.
-        mTimebaseTicksPerMillisec = speed / 1.0e4D;
-#else
-        // 68K VIA-based machines (see Develop Magazine no. 29)
-        mTimebaseTicksPerMillisec = 783.360D;
-#endif
-}
-
-unsigned long CRandomizer::SysTimer (void)      // returns the lower 32
-                                                // bit of the chip timer
-{
-#ifdef __powerc
-        return GetPPCTimer (mIs601);
-#else
-        UnsignedWide usec;
-        Microseconds (&usec);
-        return usec.lo;
-#endif
-}
-
-#ifdef __powerc
-// The timebase is available through mfspr on 601, mftb on later chips.
-// Motorola recommends that an 601 implementation map mftb to mfspr
-// through an exception, but I haven't tested to see if MacOS actually
-// does this. We only sample the lower 32 bits of the timer (i.e. a
-// few minutes of resolution)
-
-asm unsigned long GetPPCTimer (register bool is601)
-{
-        cmplwi  is601, 0        // Check if 601
-        bne     _601            // if non-zero goto _601
-        mftb    r3              // Available on 603 and later.
-        blr                     // return with result in r3
-_601:
-        mfspr r3, spr5          // Available on 601 only.
-                                // blr inserted automatically
-}
-#endif