On Thu, Sep 12, 2013 at 11:00:47AM -0400, Perry E. Metzger wrote:
>
> In addition to getting CPU makers to always include such things,
> however, a second vital problem is how to gain trust that such RNGs
> are good -- both that a particular unit isn't subject to a hardware
> defect and that the d
On Tue, Sep 10, 2013 at 10:59:37AM -0400, Marcus D. Leech wrote:
>
> Similarly, any hardware with an ADC input can be used as a hardware
> random noise source, simply by cranking up the gain to suitable
> levels where the low-order bit is sampling thermal noise.
We looked briefly at this during
On Sun, Sep 08, 2013 at 03:22:32PM -0400, Perry E. Metzger wrote:
>
> Ah, now *this* is potentially interesting. Imagine if you have a
> crypto accelerator that generates its IVs by encrypting information
> about keys in use using a key an observer might have or could guess
> from a small search s
On Sun, Sep 08, 2013 at 02:34:26PM -0400, Perry E. Metzger wrote:
>
> Any other thoughts on how one could sabotage hardware? An exhaustive
> list is interesting, if only because it gives us information on what
> to look for in hardware that may have been tweaked at NSA request.
I'd go for leaking
On Fri, Sep 06, 2013 at 07:53:42PM -0400, Marcus D. Leech wrote:
>
> One wonders why they weren't already using link encryption systems?
One wonders whether, if what we read around here lately is much guide,
they still believe they can get link encryption systems that are
robust against the only a
On Wed, Oct 06, 2010 at 01:32:00PM -0500, Matt Crawford wrote:
>
> That is, if your CA key size is smaller, stop signing with it.
You may have missed the next sentence of Mozilla's statement:
> All CAs should stop issuing intermediate and end-entity certificates with
> RSA key size smaller than 2
On Thu, Sep 30, 2010 at 05:18:56PM +0100, Samuel Neves wrote:
>
> One solution would be to use 2048-bit 4-prime RSA. It would maintain the
> security of RSA-2048, enable the reusing of the modular arithmetic units
> of 1024 bit VLSI chips and keep ECM factoring at bay. The added cost
> would only
On Thu, Sep 30, 2010 at 01:36:47PM -0400, Paul Wouters wrote:
[I wrote]:
>> Also, consider devices such as deep-inspection firewalls or application
>> traffic managers which must by their nature offload SSL processing in
>> order to inspect and possibly modify data
>
> You mean it will be harder fo
On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
> Thor Lancelot Simon writes:
>
> > a significant net loss of security, since the huge increase in computation
> > required will delay or prevent the deployment of "SSL everywhere".
>
> That wo
be used to provide feedback about the
progress of the key generation. If B is not B, it
will be called as follows:
=_1285790055-45870-1--
__
OpenSSL Project http://www.openssl.org
On Tue, Sep 14, 2010 at 08:14:59AM -0700, Paul Hoffman wrote:
> At 10:57 AM -0400 9/14/10, Perry E. Metzger did not write, but passed on for
> someone else:
> >This suggests to me that even if NIST is correct that 2048 bit RSA
> >keys are the reasonable the minimum for new deployments after 2010,
On Sun, Aug 29, 2010 at 06:40:46PM +1200, Peter Gutmann wrote:
> Thor Lancelot Simon writes:
>
> >That doesn't make any sense. DT in that generator is really meant to serve
> >the role of a counter, and, in fact, the test harness for that generator
> >*requires* i
On Sat, Aug 28, 2010 at 07:01:18PM +1200, Peter Gutmann wrote:
>
> Yup, and if you look at some of the generators you'll see things like the use
> of a date-and-time vector DT in the X9.17/X9.30 generator, which was the
> specific example I gave earlier of sneaking in seeding via the date-and-time
On Fri, Aug 27, 2010 at 07:20:06PM +1200, Peter Gutmann wrote:
>
> No. If you choose your eval lab carefully you can sneak in a TRNG somewhere
> as input to your PRNG, but you can't get a TRNG certified, and if you're
> unlucky you won't be allowed to use a TRNG at all.
I am surprised you'd have
On Fri, Aug 13, 2010 at 02:55:32PM -0500, eric.lengve...@wellsfargo.com wrote:
>
> The big drawback is that those who want to follow NIST's
> recommendations to migrate to 2048-bit keys will be returning to
> the 2005-era overhead. Dan Kaminsky provided some benchmarks in a
> different thread on t
On Wed, Aug 04, 2010 at 10:46:44PM -0700, Jon Callas wrote:
>
> I think you'll have to agree that unlike history, which starts out as
> tragedy and replays itself as farce, PKI has always been farce over the
> centuries. It might actually end up as tragedy, but so far so good. I'm
> sure that if w
On Tue, Jul 13, 2010 at 05:46:36PM +1200, Peter Gutmann wrote:
> Paul Wouters writes:
>
> >Which is what you should do anyway, in case of a hardware failure. I
> >know the Linux intel-rng and amd-rng used to produce nice series of zeros.
>
> Do you have any more details on this? Was it a hardw
On Thu, Aug 27, 2009 at 11:30:08AM +1200, Peter Gutmann wrote:
>
> Thor Lancelot Simon writes:
>
> >the exercise of recovering from new horrible problems with SHA1 would be
> >vastly simpler, easier, and far quicker
>
> What new horrible problems in SHA1 (as it&#x
On Tue, Aug 25, 2009 at 12:44:57PM +0100, Ben Laurie wrote:
> Perry E. Metzger wrote:
> > Yet another reason why you always should make the crypto algorithms you
> > use pluggable in any system -- you *will* have to replace them some day.
>
> In order to roll out a new crypto algorithm, you have t
I don't have any details of how it works (and I don't know how hard
it would be to get Broadcom to cough them up -- they seem better about
this lately than they used to be) but looking at the bcm586x product
announcement, I see they added onboard key storage.
--
Thor Lanc
he exception of parts
first sold more than 5 years ago and being shipped now from old stock.
This was once a somewhat common feature on accellerators targetted at
the SSL/IPsec market. That appears to no longer be the case.
--
Thor Lancelot Simont...@rek.
d, discontinued or obsolete products I was trying to replace.
--
Thor Lancelot Simont...@rek.tjls.com
"Even experienced UNIX users occasionally enter rm *.* at the UNIX
prompt only to realize too late that they have removed the wrong
On Sat, Mar 07, 2009 at 05:40:31AM +1300, Peter Gutmann wrote:
>
> Given that, when I looked a couple of years ago, TPM support for
> public/private-key stuff was rather hit-and-miss and in some cases seemed to
> be entirely absent (so you could use the TPM to wrap and unwrap stored private
> keys
On Fri, Jan 30, 2009 at 04:08:07PM -0800, John Gilmore wrote:
>
> The theory that we should build "good and useful" tools capable of
> monopoly and totalitarianism, but use social mechanisms to prevent
> them from being used for that purpose, strikes me as naive.
Okay. In that case, please, expl
On Thu, Jan 29, 2009 at 01:22:37PM -0800, John Gilmore wrote:
>
> If it comes from the "Trusted Computing Group", you can pretty much
> assume that it will make your computer *less* trustworthy. Their idea
> of a trusted computer is one that random unrelated third parties can
> trust to subvert th
On Mon, Jan 26, 2009 at 02:49:31AM -0500, Ivan Krsti? wrote:
>
> Finally, any idea why the Sect?ra is certified up to Top Secret for
> voice but only up to Secret for e-mail? (That is, what are the differing
> requirements?)
I know no specific details but strongly suspect the difference in
requ
On Sun, Sep 21, 2008 at 01:20:22PM -0400, James Cloos wrote:
> > "IanG" == IanG <[EMAIL PROTECTED]> writes:
>
> IanG> Nope, sorry, didn't follow it. What is BOM, SoC, A plug, gerber?
>
> Bill Of Materials -- cost of the raw hardware
> System on (a) Chip -- microchip with CPU, RAM, FLASH, e
On Thu, Aug 07, 2008 at 08:53:58AM -0400, John Ioannidis wrote:
>
> Does anyone know how this "security questions" disease started, and why
> it is spreading the way it is? If your company does this, can you find
> the people responsible and ask them what they were thinking?
When I worked at DE
> hell and back, and the result was still no damned good.
Really? From a cryptographic -- not a political -- point of view, what
exactly is wrong with DNSSEC or WPA?
WPA certainly seems to be quite widely deployed.
--
Thor Lancelot Simon[EMAIL PROTEC
On Mon, May 05, 2008 at 11:46:49AM +1000, James A. Donald wrote:
> Thor Lancelot Simon wrote:
> >And, in fact, most VPN software of any type fails this test. My concern
> >is that an excessive focus on "how hard is it to set this thing up?" can
> >seriously obscu
On Sat, May 03, 2008 at 07:50:01PM -0400, Perry E. Metzger wrote:
>
> "Steven M. Bellovin" <[EMAIL PROTECTED]> writes:
> > There's a technical/philosophical issue lurking here. We tried to
> > solve it in IPsec; not only do I think we didn't succeed, I'm not at
> > all clear we could or should ha
It's fashionable in some circles (including, it seems, this one) to bash
IPsec (particularly IKE) and tout SSL VPNs (particularly OpenVPN) on what
are basically user interface grounds.
I cannot help repeatedly noting that -- I believe more so than with actual
IPsec deployments, whether with or wit
On Thu, Jan 31, 2008 at 04:07:03PM +0100, Guus Sliepen wrote:
>
> Peter sent us his write-up up via private email a few days before he
> posted it to this list (which got it on Slashdot). I had little time to
> think about the issues he mentioned before his write-up became public.
> When it did, I
On Fri, Dec 14, 2007 at 08:33:16AM -0800, Joshua Hill wrote:
>
> You may be confusing the requirements for a KAT which is a power-up health
> check on all of the deterministic components of the PRNG (which is run on
> power-up and requires that you fix all the inputs to some specific known
> value
On Tue, Dec 11, 2007 at 04:00:42PM -0500, Leichter, Jerry wrote:
> | > It is, of course, the height of irony that the bug was introduced in
> | > the very process, and for the very purpose, of attaining FIPS
> | > compliance!
> |
> | But also to be expected, because the feature in question is
> |
On Mon, Sep 03, 2007 at 04:27:22PM -0400, Vin McLellan wrote:
> Thor Lancelot quoted that, and erupted with sanctimonious umbrage:
>
> >>I think it's important that we know, when flaws in commercial
> >>cryptographic products are being discussed, what the interests of the
> >>parties to the discus
On Sun, Sep 02, 2007 at 06:26:33PM -0400, Vin McLellan wrote:
> At 12:40 PM 9/2/2007, Paul Walker wrote:
>
> >I didn't realise the current SecurID tokens had been broken. A quick Google
> >doesn't show anything, but I'm probably using the wrong terms. Do you have
> >references for this that I coul
On Mon, Aug 20, 2007 at 11:42:39AM -0400, Peter Thermos wrote:
>
> "We can confirm categorically that no malicious activities were attributed
> or that our users' security was not, at any point, at risk."
One wonders if it was their attorneys who suggested that they confirm
categorically that "x
On Sun, Jul 01, 2007 at 08:38:12AM -0400, Perry E. Metzger wrote:
>
> [EMAIL PROTECTED] (Peter Gutmann) writes:
> > (The usage model is that you do the UI portion on the PC, but
> > perform the actual transaction on the external device, which has a
> > two-line LCD display for source and destinati
On Thu, May 24, 2007 at 01:01:03PM -0400, Perry E. Metzger wrote:
>
> Even for https, it costs no more to type in "2048" than "1024" into
> your cert generation app the next time a cert expires. The only
> potential cost is if you're so close to the performance line that
> slower RSA ops will caus
On Wed, May 09, 2007 at 01:13:36AM -0500, Travis H. wrote:
> On Fri, Apr 27, 2007 at 05:13:44PM -0400, Leichter, Jerry wrote:
> > Frankly, for SSH this isn't a very plausible attack, since it's not
> > clear how you could force chosen plaintext into an SSH session between
> > messages. A later pap
On Thu, Apr 05, 2007 at 05:30:53PM -0700, Paul Hoffman wrote:
> At 7:54 PM -0400 4/5/07, Thor Lancelot Simon wrote:
> >
> >You're missing the point. The root just signs itself a new .net key,
> >and then uses that to sign a new furble.net key, and so forth. No
>
On Thu, Apr 05, 2007 at 04:49:33PM -0700, Paul Hoffman wrote:
>
> >because, with it, one can sign the appropriate
> >chain of keys to forge records for any zone one likes.
>
> If the owner of any key signs below their level, it is immediately
> visible to anyone doing active checking. The root s
On Thu, Apr 05, 2007 at 07:32:09AM -0700, Paul Hoffman wrote:
>
> Control: The root signing key only controls the contents of the root,
> not any level below the root.
That is, of course, false, and presumably is _exactly_ why DHS wants
the root signing key: because, with it, one can sign the ap
On Fri, Jan 26, 2007 at 11:42:58AM -0500, Victor Duchovni wrote:
> On Fri, Jan 26, 2007 at 07:06:00PM +1300, Peter Gutmann wrote:
>
> > In some cases it may be useful to send the entire chain, one such being
> > when a
> > CA re-issues its root with a new expiry date, as Verisign did when its roo
On Tue, Dec 26, 2006 at 05:36:42PM +1300, Peter Gutmann wrote:
>
> In addition I've heard of evaluations where the generator is required to use a
> monotonically increasing counter (clock value) as the seed, so you can't just
> use the PRNG as a postprocessor for an entropy polling mechanism. The
On Sat, Dec 02, 2006 at 05:15:02PM -0500, John Ioannidis wrote:
> On Sat, Dec 02, 2006 at 10:21:57AM -0500, Perry E. Metzger wrote:
> >
> > Quoting:
> >
> >The FBI appears to have begun using a novel form of electronic
> >surveillance in criminal investigations: remotely activating a
> >
On Thu, Oct 05, 2006 at 11:51:49PM +0200, Erik Tews wrote:
> Am Donnerstag, den 05.10.2006, 16:25 -0500 schrieb Travis H.:
> > On 10/2/06, Erik Tews <[EMAIL PROTECTED]> wrote:
> > > Am Sonntag, den 01.10.2006, 23:42 -0500 schrieb Travis H.:
> > > > Anyone have any information on how to develop TPM
On Wed, Sep 13, 2006 at 10:23:53PM -0400, Vin McLellan wrote:
>
[... a long message including much of what I can only regard as
outright advertising for RSA, irrelevant to the actual technical
weakness in the SID800 USB token that Hadmut described, and which
Vin's message purportedly disputes.
On Mon, Sep 11, 2006 at 06:18:06AM +1000, James A. Donald wrote:
>
> 3. No one actually uses DNSSEC in the wild.
DNSSEC seems to be not-uncommonly used to secure dynamic updates,
which is not the most common DNS feature in the world but it is not
so uncommon either.
---
On Mon, Aug 07, 2006 at 05:12:45PM -0700, John Gilmore wrote:
>
> The good news is that CAcert seems to be posistioned for prime time debut,
> and you can't beat *Free*. :-)
You certainly can, if slipshod practices end up _costing_
you money.
Has CAcert stopped writing certificates with no DN y
such as radioactive-decay
or "more direct" (than junction noise) quantum or thermal noise sources;
I just want to understand why all the public domain designs are of one
type, and all the commercial designs of the other.
--
Thor Lancelot Simon[
On Fri, Jul 28, 2006 at 06:46:54PM -0600, Anne & Lynn Wheeler wrote:
> Thor Lancelot Simon wrote:
> >The simple, cost-effective solution, then, would seem to be to generate
> >"static serial numbers" like cipher keys -- with sufficient randomness
> >and l
On Fri, Jul 28, 2006 at 03:52:55PM -0600, Anne & Lynn Wheeler wrote:
> Thor Lancelot Simon wrote:
> >I don't get it. How is there "no increase in vulnerability and threat"
> >if a manufacturer of counterfeit / copy chips can simply read the already
> >g
On Thu, Jul 27, 2006 at 08:53:26PM -0600, Anne & Lynn Wheeler wrote:
>
> If you treat it as a real security chip (the kind that goes into
> smartcards and hardware token) ... it eliminates the significant
> post-fab security handling (prior to finished delivery), in part to
> assure that counte
On Tue, Jul 25, 2006 at 03:49:11PM -0600, Anne & Lynn Wheeler wrote:
> Perry E. Metzger wrote:
> >EE Times is carrying the following story:
> >
> >http://www.eetimes.com/news/latest/showArticle.jhtml?articleID=190900759
> >
> >It is about attempts to use cryptography to protect chip designs from
>
vendor who makes it,
I strongly urge you to make disclosure of how it works, including any
analysis they've done, a condition of your use of their product. The
Intel and Hifn white papers are good examples of what *every* vendor
should be willing to publically disclose, if their RNG design do
the contrary.
--
Thor Lancelot Simon[EMAIL PROTECTED]
"We cannot usually in social life pursue a single value or a single moral
aim, untroubled by the need to compromise with others." - H.L.A. Hart
-
houting out a comparison of vendor capabilites to the
entire world (though I do think it is regrettable that there's a lack
of information on this kind of device capability anywhere public).
--
Thor Lancelot Simon[EMAIL PROTECTED]
"We cannot
forget that two such certificates were issued to a party
(identity, AFAIK, still unknown) claiming to be Microsoft? What,
exactly, do you think that party's plans for those certificates
were -- and why, exactly, do you think they were inocuous?
Thor Lancelot Simon
On Tue, Jun 21, 2005 at 10:38:42PM -0400, Perry E. Metzger wrote:
>
> Jerrold Leichter <[EMAIL PROTECTED]> writes:
> > Usage in first of these may be subject to Bernstein's attack. It's much
> > harder to see how one could attack a session key in a properly implemented
> > system the same way.
On Wed, Jun 16, 2004 at 02:12:18PM -0700, Eric Rescorla wrote:
>
> Let's assume for the sake of argument that two people auditing
> the same code section will find the same set of bugs. So, how
> to account for the fact that obvious errors persist for long
> periods of time in popular code bases?
On Tue, Jun 15, 2004 at 09:37:42PM -0700, Eric Rescorla wrote:
> "Arnold G. Reinhold" <[EMAIL PROTECTED]> writes:
> > My other concern with the thesis that finding security holes is a bad
> > idea is that it treats the Black Hats as a monolithic group. I would
> > divide them into three categories:
On Mon, Jun 14, 2004 at 08:07:11AM -0700, Eric Rescorla wrote:
> in the paper.
>
> Roughly speaking:
> If I as a White Hat find a bug and then don't tell anyone, there's no
> reason to believe it will result in any intrusions. The bug has to
I don't believe that the premise above is valid. To
t all, no, really, nobody, not
ever, nowhere, did with a comparatively immense amount of computing power;
but that's a secondary reason; I'd also like to read it because I've heard
here and there that there are some really great stories in there, if only...
well, you get the idea.
On Thu, Nov 27, 2003 at 02:45:47PM +1100, Greg Rose wrote:
> At 12:27 PM 11/27/2003, Thor Lancelot Simon wrote:
> >RC4 is extremely weak for some applications. A block cipher is greatly
> >preferable.
>
> I'm afraid that I can't agree with this howling logical e
On Wed, Nov 26, 2003 at 02:56:40PM -0800, J Harper wrote:
> Great feedback, let me elaborate. I realize that AES is implemented in
> hardware for many platforms as well. I'll mention a bit more about our
> cryptography architecture below. Do you know why AES is so popular in
> embedded? ARC4 is
On Wed, Oct 22, 2003 at 05:08:32PM -0400, Tom Otvos wrote:
> >
> > So what purpose would client certificates address? Almost all of the use
> > of SSL domain name certs is to hide a credit card number when a consumer
> > is buying something. There is no requirement for the merchant to
> > identify
On Sun, Oct 19, 2003 at 01:42:34AM -0600, Damien Miller wrote:
> On Sun, 2003-10-19 at 00:47, Peter Gutmann wrote:
>
> > >What was the motive for adding lip service into the document?
> >
> > So that it's possible to claim PGP and X.509 support if anyone's interested in
> > it. It's (I guess) so
On Thu, Oct 09, 2003 at 07:45:01PM -0700, Bill Frantz wrote:
> At 8:18 AM -0700 10/7/03, Rich Salz wrote:
> >Are you validating the toolchain? (See Ken Thompson's
> >Turing Aware lecture on trusting trust).
>
> With KeyKOS, we used the argument that since the assembler we were using
> was written
On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote:
> Thor Lancelot Simon wrote:
>
> > On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:
> >
> >>Thor Lancelot Simon wrote:
> >>
> >>>these operations. For example, there is no s
On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote:
> Thor Lancelot Simon wrote:
> > As far as what OpenSSL does, if you simply abandon outright any hope of
> > acting as a certificate authority, etc. you can punt a huge amount of
> > complexity; if you punt SSL, yo
On Fri, Oct 03, 2003 at 04:31:26PM -0400, Tyler Close wrote:
> On Thursday 02 October 2003 09:21, Jill Ramonsky wrote:
> > I was thinking of doing a C++ implentation with classes and
> > templates and stuff. (By contrast OpenSSL is a C
> > implementation). Anyone got any thoughts on that?
>
> Giv
On Thu, Oct 02, 2003 at 02:21:29PM +0100, Jill Ramonsky wrote:
>
> Thanks everyone for the SSL encouragement. I'm going to have a quick
> re-read of Eric's book over the weekend and then start thinking about
> what sort of "easy to use" implementation I could do. I was thinking of
> doing a C++
On Wed, Oct 01, 2003 at 10:20:53PM +0200, Guus Sliepen wrote:
>
> You clearly formulated what we are doing! We want to keep our crypto as
> simple and to the point as necessary for tinc. We also want to
> understand it ourselves. Implementing our own authentication protocol
> helps us do all that.
On Mon, Sep 15, 2003 at 12:57:55PM -0400, Wei Dai wrote:
>
> I think I may have found such a written guidance myself. It's guidance
> G.5, dated 8/6/2003, in the latest "Implementation Guidance for FIPS
> 140-2" on NIST's web site:
> http://csrc.nist.gov/cryptval/140-1/FIPS1402IG.pdf. This sect
On Mon, Sep 08, 2003 at 10:49:02AM -0600, Tolga Acar wrote:
> On a second thought, that there is no key management algorithm
> certified, how would one set up a SSL connection in FIPS mode?
>
> It seems to me that, it is not possible to have a FIPS 140 certified
> SSL/TLS session using the OpenS
On Wed, Sep 03, 2003 at 08:25:54AM -0700, Joshua Hill wrote:
> On Fri, Aug 29, 2003 at 03:45:50PM -0400, Thor Lancelot Simon wrote:
>
> > However, it has always been permitted
> > to use a free-running counter instead of the time, and indeed the current
> > interpretation
On Tue, Sep 02, 2003 at 12:10:23PM -0400, Anton Stiglic wrote:
>
> Right. So I don't actually have the original ANSI X9.17 document (and it is
> no longer available in the ANSI X9 catalogue). My references are
> HAC section 5.3.1
> http://www.cacr.math.uwaterloo.ca/hac/about/chap5.pdf
> and Kels
ible.
I do have some more thoughts on the quality of the various generators
the standard allows but I haven't had time to get them down in writing;
I'll try to do so before this thread is totally stale...
--
Thor Lancelot Simon [EMAIL PROTECTED]
On Fri, Aug 22, 2003 at 10:00:14AM -0700, Bob Baldwin PlusFive wrote:
> Tim,
> One issue to consider is whether the system
> that includes the PRNG will ever need a FIPS-140-2
> rating. For example, people are now working on
> a FIPS-140 validation for OpenSSL. If so, then
> the generator fo
On Tue, Jul 08, 2003 at 02:20:46PM -0700, Eric Murray wrote:
>
> For comparison purposes, I have a copy of an SSLv3/TLS client library
> I wrote in 1997. It's 56k of (Intel Linux) code for everything
> except RSA. That includes the ASN.1 and X.509 parser.
> Implementing the server-specific par
On Tue, Jul 08, 2003 at 09:18:53PM +0100, M Taylor wrote:
> On Tue, Jul 08, 2003 at 12:19:54PM -0700, Eric Rescorla wrote:
> >
> > As I said before, the problem here isn't SSL. Rather, it's the way
> > that OpenSSL does things. Now, it would be a real contribution for
> > you to write a simple wra
On Sat, Jun 28, 2003 at 01:06:03PM -0700, Bill Stewart wrote:
> Somebody did an interesting attack on a cable network's customers.
> They cracked the cable company's DHCP server, got it to provide a
> "Connection-specific DNS suffic" pointing to a machine they owned,
> and also told it to use their
84 matches
Mail list logo
