Cryptography-Digest Digest #144, Volume #14 Sat, 14 Apr 01 21:13:00 EDT
Contents:
Re: LFSR Security ("Trevor L. Jackson, III")
Re: LFSR Security ("Trevor L. Jackson, III")
Re: LFSR Security ("Trevor L. Jackson, III")
Re: LFSR Security ("Trevor L. Jackson, III")
Re: LFSR Security ("Trevor L. Jackson, III")
Re: How good is steganography in the real world? (Charles Lyttle)
Re: LFSR Security (David Wagner)
Re: LFSR Security (David Wagner)
Re: NSA is funding stegano detection (Mok-Kong Shen)
Re: NSA is funding stegano detection (Niels Provos)
Re: NSA is funding stegano detection (Mok-Kong Shen)
Re: MS OSs "swap" file: total breach of computer security. (Ben Cantrick)
XOR_TextBox: Doesn't write to swap file if... (Anthony Stephen Szopa)
Re: XOR_TextBox: Doesn't write to swap file if... ("Tom St Denis")
Re: MS OSs "swap" file: total breach of computer security. (Anthony Stephen Szopa)
Re: LFSR Security ("Scott Fluhrer")
Re: MS OSs "swap" file: total breach of computer security. ("Tom St Denis")
Re: LFSR Security (David Wagner)
Re: MS OSs "swap" file: total breach of computer security. ("Henrick Hellström")
Re: Rabin-Miller prime testing (DJohn37050)
Re: MS OSs "swap" file: total breach of computer security. (Tom McCune)
----------------------------------------------------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 22:21:33 GMT
"Nathan E. Banks " wrote:
> [Crossposted to sci.crypt.random-numbers]
>
> Hi everyone! Crypto is sort of a hobby of mine, although I'm no sort of
> master. Most of the advanced math is a bit over my head. :) Anyway, I've
> lurked here off and on in the past... you may have seen one of my LFSR
> threads in the past.
>
> Anyway, I'm wondering about the strength of 16 bit LFSRs. Given a stream
> of pseudorandom bits generated by a 16 bit LFSR, how difficult would it
> be to reverse engineer the stream to determine the starting state of the
> LFSR?
Very simple. There are only 2^16-1 configurations (far fewer of maximal
period) and 2^16-1 initial states. By brute force one can generate all ~2^32
possibilities and run the result against a dictionary to screen out the pure
nonsense. Within a few minutes a human could scan a list of the messages
containing a dictionary entry, and the key would be determined.
>
>
> Expanding on this, given some cyphertext generated by XORing the above
> stream with some plaintext, how hard would it be to reverse engineer the
> cyphertext to determine the key (assuming that the key is a 16 bit value
> used to initialize the LFSR)?
>
> How would this be affected by using multiple LFSRs (say 8) initialized
> from a single large key (say 128 bit) and XORing the outputs together?
Harder, but not much. Since the period of the system would be unchanged at
65535 cycles one does not need to search for all 128 bits of key, but only
for an equivalent 16-bit generator. If the wiring of the registers is
unknown the Berkelecamp-Massey method can be used to find it.
>
>
> With a 16 bit LFSR you have a keyspace of 65535, so I imagine that it
> wouldn't take very long for a computer to try all possible keys in a
> brute force attack. But how would the computer know when it had the
> correct key? It takes a lot longer for a human operator to examine every
> possible output for one that makes sense than it does for a computer just
> to run through all possible keys.
The human does not have to inspect every output, but only the residual output
after extensive filtration with a dictionary.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 22:24:40 GMT
"Nathan E. Banks " wrote:
> In article <9ba9r9$ftk$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> > Nathan E. Banks wrote:
>
> > XORing multiple LFSRs doesn't help, no matter how big they are.
>
> Hmm. In a private email someone told me that XORing multiple LFSRs would
> help a lot, especially if they were of different sizes. Could someone
> explain why one or the other is true? :)
If the registers are the same size the XOR of their outputs has the same
period of the component generators. If the registers are different sizes,
and the periods are co-prime, then the XOR of their outputs is the product
of the component periods. This is very slightly more complex, but not worth
the effort for security. It can be worth the effort for constructing a long
period PRNG for simulation and statistical purposes.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 22:28:02 GMT
"Nathan E. Banks " wrote:
> In article <9babri$gav$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> > Nathan E. Banks wrote:
> > >Hmm. In a private email someone told me that XORing multiple LFSRs would
> > >help a lot, especially if they were of different sizes. Could someone
> > >explain why one or the other is true? :)
> >
> > They were wrong. The sequence produced by an XOR of two LFSRs of
> > size M and N can be equivalently produced by a LFSR of size M+N.
> > The Berlekamp-Massey algorithm can then recover the initial state
> > and feedback taps with 2(M+N) bits of known keystream. Read up on
> > Berlekamp-Massey if you want to know why this is true.
>
> Is there an explanation anywhere that's a bit more straightforward than
> the one in Handbook of Applied Cryptography? It's a bit... obtuse, at
> least for people like me who have math that only goes up to calculus.
It has nothing to do with higher math, but everything to do with the insecurity
of linear systems. The Ell in LFSR stands for linear. This means that LFSR
systems are not secure. Adding them together does not reduce the linearity, so
it does not reduce the weakness.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 22:32:51 GMT
David Wagner wrote:
> Tom St Denis wrote:
> >Question: Does the BM algorithm apply when non consecutive outputs are
> >known?
>
> I don't know. The standard formulation requires 2n bits of consecutive
> known keystream, but I don't know whether their techniques can be extended
> to handle the case where the known keystream bits are not consecutive.
> It's an interesting question....
I believe this is actually two questions. If the sizes of the gaps are known
then it should be straightforward to adjust the solution matrix to account for
them.
If the sizes of the gaps are unknown I think there is no possible solution by
the Nyquist principle. Even the intermediate case where all of the samples
are from a single cycle of the generator has too many unknowns to produce a
single result.
------------------------------
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 22:34:30 GMT
Tom St Denis wrote:
> "David Wagner" <[EMAIL PROTECTED]> wrote in message
> news:9bagpk$h5e$[EMAIL PROTECTED]...
> > Tom St Denis wrote:
> > >Question: Does the BM algorithm apply when non consecutive outputs are
> > >known?
> >
> > I don't know. The standard formulation requires 2n bits of consecutive
> > known keystream, but I don't know whether their techniques can be extended
> > to handle the case where the known keystream bits are not consecutive.
> > It's an interesting question....
>
> Wouldn't a secure LFSR just be one where you dump say N bits then output 1
> ... That way the output picture is incomplete...
As soon as you have 2N bits regularly sampled you can solve for the initial
state. If the samples are taken at irregular intervals but known I think it is
still solvable.
>
>
> My naive instinct says "NO BAD IDEA TOM" but I am not sure... (not sure
> about much, which makes me a dork and a amateur!).
>
> Tom
------------------------------
From: Charles Lyttle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: How good is steganography in the real world?
Date: Sat, 14 Apr 2001 22:34:40 GMT
As an interesting aside, the movie "Along Came a Spider" features
steganography as a plot element. Kids were using it to pass messages
and, perhaps, cheat, in class.
Gil Adamson wrote:
>
> Hello, all. I've been doing a bit of research on cryptography and how
> it might be applied to a scenario that our company has. I think I
> understand some of the basic concepts, but I wanted to get more expert
> opinions before I make any recommendations to our management.
>
> I hope you'll excuse me if I leave out some of the specifics of our
> situation below:
>
> I'm a technology advisor for a small company that has operations in
> several locations around the world, one of which is (believe it or not)
> Iraq. For various reasons, it is sometimes important for our workers
> to communicate fairly sensitive information to us via e-mail. Also for
> various reasons, we can never be sure that our e-mail will not pass
> through some centrally-located, government-controlled server.
> Therefore we have to assume that ANY (or all) e-mail messages to/from
> our employees there can be read.
>
> Certainly it would be possible to encrypt the messages using some
> strong cipher that we could be relatively certain would be unbreakable,
> at least without great effort. However, our situation there is such
> that the very *discovery* of an encrypted message, though
> unbreakable, would itself raise unwanted suspicion.
>
> The goal then is to send information in such a way that the very
> existence of a private message cannot be seen or suspected.
>
> Given that, I've focused my research on steganography. In particular,
> I've been considering a product called S-Tools, mainly because it
> supports GIFs and produces images that contain hidden data but are
> almost imperceptibly different from the original GIF. (Plus the fact
> that it supports Triple-DES and other strong ciphers). I couldn't find
> a lot of information on stegananalysis (e.g. how easy is it to discover
> a hidden message in images), but this article
> (http://www.jjtc.com/ihws98/jjgmu.html) seemed to indicate that S-Tools
> was better than most if not all image steganography packages.
>
> I guess my question really boils down to, how safe a method IS this,
> really? It would SEEM to me that it would be very unlikely that
> someone could discover that a hidden message is being sent (much less
> decrypt the message), but is that really true? Or would governmental
> agencies in foreign countries have a greater ability to analyze and
> identify steganographic images than one might think at first?
>
> To put it another way, what criteria should we use when deciding
> whether to use this technique or not? When management says "That looks
> good, but what are the chances that someone will discover the images
> contain hidden messages", what do I tell them? How do you quantify
> risk?
>
> There's no question that sending encoded messages in ANY form (well,
> maybe other than with a one-time pad) poses some risk of discovery.
> The question is, how MUCH of a risk would something like this be? I
> know that's a hard thing to quantify, but is it possible to get it
> within a factor of 10 or so? Is the chance of discovery 0.1%? 1%? 10%?
>
> A lot is at stake for our company. If the risk of discovery is too
> high, it might be best just to limit communication of any critical
> information (inconvenient as that might be). But if the risk is very
> small, the benefit might outweigh the risk.
>
> Before I give me recommendations to management, I want to be sure I
> have a clear understanding of what the risks are. So thanks very much
> to anyone who can help.
--
Russ Lyttle
"World Domination through Penguin Power"
The Universal Automotive Testset Project at
<http://home.earthlink.net/~lyttlec>
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 14 Apr 2001 22:46:56 GMT
Trevor L. Jackson, III wrote:
>As soon as you have 2N bits regularly sampled you can solve for the initial
>state.
Even when the taps are unknown and part of the key? If so, how?
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 14 Apr 2001 22:48:40 GMT
Trevor L. Jackson, III wrote:
>David Wagner wrote:
>> Tom St Denis wrote:
>> >Question: Does the BM algorithm apply when non consecutive outputs are
>> >known?
>>
>> I don't know. The standard formulation requires 2n bits of consecutive
>> known keystream, but I don't know whether their techniques can be extended
>> to handle the case where the known keystream bits are not consecutive.
>> It's an interesting question....
>
>I believe this is actually two questions. If the sizes of the gaps are known
>then it should be straightforward to adjust the solution matrix to account for
>them.
I think we're thinking about different questions.
The matrix method I outlined only applies when the taps are known,
and works for any n bits (consecutive, regularly-spaced, or not).
Berlekamp-Massey applies when the taps are unknown, but apparently
requires 2n consecutive bits.
The non-trivial question is: Can Berlekamp-Massey be extended to
break a LFSR with unknown taps given some number of non-consecutive
bits of the keystream?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Sun, 15 Apr 2001 00:48:54 +0200
Niels Provos wrote:
>
[snip]
> Just embedding all your data in the LSB is problematic,
> and probably easy to detect. There has been some research in that
> area. I wrote two related papers which you can find at
[snip]
Could you please give some hints/ideas of how does one
go about to detect that, if the picture is sender's own
(i.e. there is no 'reference') and only a small fraction
of the pixels have LSB of one colour modified (the
positions of the modifications being pseudo-randomly
determined)? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Niels Provos)
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: 14 Apr 2001 23:24:35 GMT
On Sun, 15 Apr 2001 00:48:54 +0200, Mok-Kong Shen wrote:
>Could you please give some hints/ideas of how does one
>go about to detect that, if the picture is sender's own
>(i.e. there is no 'reference') and only a small fraction
>of the pixels have LSB of one colour modified (the
>positions of the modifications being pseudo-randomly
>determined)? Thanks.
Essentially, you trade off hiding capacity against security.
The more data you hide, the easier it will become to detect
distortions in the statiscial properties of an image. If
your pseudo-random selection considers only LSB values, you
neglect statistical properties that depend on the whole value,
e.g. coefficient frequency in JPG.
Let's take an image from my digital camera as an example and
jphide as steganographic system. Jphide modifies the LSBs of
the JPG quantized DCT coefficients pseudo-randomly.
The original image
$ stegdetect dscf0001.jpg
dscf0001.jpg : negative
After using jphide to embed a 5.5KB sized message, we get
the following result
$ ls -l dscf0001.jpg
-rw-r--r-- 1 provos wheel 44336 Apr 1 15:21 dscf0001.jpg
$ stegdetect dscf0001.jpg
dscf0001.jpg : jphide(***)
Looking more closely,
$ stegdetect -tp -d96 dscf0001.jpg
0000: 64.08565%
0001: 82.94236%
0002: 91.43586%
0003: 88.56253%
[...]
0096: 97.02263%
0097: 98.91465%
0098: 99.26532%
0099: 95.76497%
0100: 95.76497%
Accumulation ( 5.5%): 3968.117142%
dscf0001.jpg : jphide(***)
The same image with 4.3KB embedded:
Accumulation ( 6.3%): 3156.123734%
dscf0001.jpg : jphide(***)
with 4KB embedded:
dscf0001.jpg : negative
As you see, it all boils down to how small small is, and
the sophistication of your adversary.
--
Niels Provos <[EMAIL PROTECTED]> finger [EMAIL PROTECTED] for pgp info
"Gravity is the soul of weight." - Anonymous.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,talk.politics.crypto
Subject: Re: NSA is funding stegano detection
Date: Sun, 15 Apr 2001 01:44:16 +0200
Niels Provos wrote:
>
> Essentially, you trade off hiding capacity against security.
> The more data you hide, the easier it will become to detect
> distortions in the statiscial properties of an image. If
> your pseudo-random selection considers only LSB values, you
> neglect statistical properties that depend on the whole value,
> e.g. coefficient frequency in JPG.
[snip]
But aren't the statistical properties of an image
dependent on the image? There is no 'standard' of such
properties, isn't it? Now the opponent doesn't
have the original image. He has no idea of the 'correct'
statistical properties. How does he know that the
modified statisitical properties aren't really
the genuine ones?
Another question, between modifying the LSB of the pixels
and modifying the LSB of DCT coefficients, which approach
is better, why?
Thanks in advance.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: 14 Apr 2001 18:16:09 -0600
In article <nR3C6.8436$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>"AY" <[EMAIL PROTECTED]> wrote in message
>news:9bad2r$h88$[EMAIL PROTECTED]...
>> >MS is intentionally placing our right
>> >to privacy at risk.
>>
>> There are easier ways for MS to invate the user's privacy than deliberately
>> implementing a insecure swap file system. In any case I think better
>> programming _could_ help with the swap file security issues.
>
>"Secure swap file" is almost an oxymoron.
How so? I think OpenBSD does it rather well...
> I dunno. A lot of desktop machines have oodles of ram afaik (mine
>has 384mb... my bro has +400mb... my friend has 192mb... etc)... swap
>files "should" be obsolete.
Swap files will never be obselete. As soon as you give people more
memory or CPU power they immediately do stupid, inefficient, lazy things
and use it all up. Swap files will be with us as long as there are
programmers who care more about getting a paycheck than writing good code.
(Which is most of them. I know, I work with them every day.)
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
I plead contemporary insanity.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: XOR_TextBox: Doesn't write to swap file if...
Date: Sat, 14 Apr 2001 17:13:44 -0700
XOR_TextBox: Doesn't write to swap file if...
Excerpt from updated Version 1.2 Instructions:
"I have a 256MB RAM computer running Windows '98. When I run
XOR_TextBox there is no writing to the WIN386.SWP swap file. In
other words, the entered or displayed text is only stored in RAM.
If you have less RAM, the text you enter or display may be written
to this swap file. Because you normally have no control over or
access to this swap file, writing to it may be an unacceptable
security risk.
Here is how you can check to see if your computer is writing to the
WIN386.SWP swap file when using XOR_TextBox on your computer..."
In Version 1.1 a progress bar was added to the status bar, and an XOR
process completion notification was also added to the status bar.
In Version 1.2 additional help and explanations were added to
the Instructions clarifying any swap file issue..
Thanks for all of your feedback.
Cheers.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: XOR_TextBox: Doesn't write to swap file if...
Date: Sun, 15 Apr 2001 00:25:20 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> XOR_TextBox: Doesn't write to swap file if...
>
> Excerpt from updated Version 1.2 Instructions:
>
> "I have a 256MB RAM computer running Windows '98. When I run
> XOR_TextBox there is no writing to the WIN386.SWP swap file. In
> other words, the entered or displayed text is only stored in RAM.
> If you have less RAM, the text you enter or display may be written
> to this swap file. Because you normally have no control over or
> access to this swap file, writing to it may be an unacceptable
> security risk.
>
> Here is how you can check to see if your computer is writing to the
> WIN386.SWP swap file when using XOR_TextBox on your computer..."
>
> In Version 1.1 a progress bar was added to the status bar, and an XOR
> process completion notification was also added to the status bar.
>
> In Version 1.2 additional help and explanations were added to
> the Instructions clarifying any swap file issue..
>
> Thanks for all of your feedback.
Again you are playing with fire because you don't understand how the OS
works.... even with my 384mb of ram I could have your app swap to disk.
Having huge amounts of ram is not a solution. Locking the memory is. You
just don't learn do you? Why not look up the Win32 reference for
GlobalAlloc and GlobalLock afaik they are functions you should be concerned
with.
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Sat, 14 Apr 2001 17:32:06 -0700
AY wrote:
>
> >MS is intentionally placing our right
> >to privacy at risk.
>
> There are easier ways for MS to invate the user's privacy than deliberately
> implementing a insecure swap file system. In any case I think better
> programming _could_ help with the swap file security issues.
>
> >The only discretion one has at this time is to NOT use any leaky MS
> >security sieve of an OS.
>
> Hmm....
> > X-Mailer: Mozilla 4.7 [en] (Win98; I)
I just made a post regarding my XOR_TextBox software (many
expressed grave concerns about it) addressing this very issue.
You must first know the function before you need to know the
implementation of a swap file procedure.
If you have sufficient RAM then the swap file, apparently, is not
utilized.
You may want to take a quick look at that post.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: Sat, 14 Apr 2001 17:29:20 -0700
David Wagner <[EMAIL PROTECTED]> wrote in message
news:9bak10$hnq$[EMAIL PROTECTED]...
> Trevor L. Jackson, III wrote:
> >As soon as you have 2N bits regularly sampled you can solve for the
initial
> >state.
>
> Even when the taps are unknown and part of the key? If so, how?
Simple: the output of an length N LFSR, sampled once every M outputs, is
identical to the output of another length N LFSR with possibly different
taps. So, all you need to do is run the BM algorithm on the virtual LFSR.
If you want to, you can translate the results back to the original LFSR.
--
poncho
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Sun, 15 Apr 2001 00:52:51 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> AY wrote:
> >
> > >MS is intentionally placing our right
> > >to privacy at risk.
> >
> > There are easier ways for MS to invate the user's privacy than
deliberately
> > implementing a insecure swap file system. In any case I think better
> > programming _could_ help with the swap file security issues.
> >
> > >The only discretion one has at this time is to NOT use any leaky MS
> > >security sieve of an OS.
> >
> > Hmm....
> > > X-Mailer: Mozilla 4.7 [en] (Win98; I)
>
>
>
> I just made a post regarding my XOR_TextBox software (many
> expressed grave concerns about it) addressing this very issue.
>
> You must first know the function before you need to know the
> implementation of a swap file procedure.
>
> If you have sufficient RAM then the swap file, apparently, is not
> utilized.
>
> You may want to take a quick look at that post.'
Take a look at my reply to your post :-o
Tom
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Crossposted-To: sci.crypt.random-numbers
Subject: Re: LFSR Security
Date: 15 Apr 2001 00:53:09 GMT
Scott Fluhrer wrote:
>> >As soon as you have 2N bits regularly sampled you can solve for the
>> >initial state.
>> [...] How? [...]
>
>Simple: the output of an length N LFSR, sampled once every M outputs, is
>identical to the output of another length N LFSR with possibly different
>taps. So, all you need to do is run the BM algorithm on the virtual LFSR.
>If you want to, you can translate the results back to the original LFSR.
Ahh, very clever.
Ok, so can this be extended any further? Suppose I have some bits
of known keystream that are neither consecutive nor regularly spaced
and that come from a LFSR with unknown taps. Can this be broken?
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Sun, 15 Apr 2001 02:54:41 +0200
One solution that just might be effective against disk forensics (but not
trojans) is to create three or more random keys, store these keys in global
memory, start up three different processes to manage each of these keys, and
use the keys to encrypt all sensitive internal data. If you are lucky, the
internal memory of all four processes will not end up in the swap file
simultaneously. But recommending the user to turn of virtual memory
completely would probably be the best thing to do.
--
Henrick Hellström [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> AY wrote:
> >
> > >MS is intentionally placing our right
> > >to privacy at risk.
> >
> > There are easier ways for MS to invate the user's privacy than
deliberately
> > implementing a insecure swap file system. In any case I think better
> > programming _could_ help with the swap file security issues.
> >
> > >The only discretion one has at this time is to NOT use any leaky MS
> > >security sieve of an OS.
> >
> > Hmm....
> > > X-Mailer: Mozilla 4.7 [en] (Win98; I)
>
>
>
> I just made a post regarding my XOR_TextBox software (many
> expressed grave concerns about it) addressing this very issue.
>
> You must first know the function before you need to know the
> implementation of a swap file procedure.
>
> If you have sufficient RAM then the swap file, apparently, is not
> utilized.
>
> You may want to take a quick look at that post.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 15 Apr 2001 01:01:05 GMT
Subject: Re: Rabin-Miller prime testing
ANSI X9 does 50 MR tests as one option. If you are generating, you can use
fixed bases, if you are validating (from someone else), you must use random
bases.
Don Johnson
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: MS OSs "swap" file: total breach of computer security.
Date: Sun, 15 Apr 2001 01:00:11 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <9bargb$293$[EMAIL PROTECTED]>, "Henrick Hellström"
<[EMAIL PROTECTED]> wrote:
>One solution that just might be effective against disk forensics (but
>not trojans) is to create three or more random keys, store these keys in
>global memory, start up three different processes to manage each of
>these keys, and use the keys to encrypt all sensitive internal data. If
>you are lucky, the internal memory of all four processes will not end up
>in the swap file
>simultaneously. But recommending the user to turn of virtual memory
>completely would probably be the best thing to do.
I think my solution works pretty well. I doubled my RAM to 256 meg, set
ConservativeSwapfileUsage=1
in System.ini [386Enh]
and set my swap file to a firm 150 meg.
That lets me have a swap file that takes care of Allocated Memory needs
so I can use my RAM, keeps anything out of my swap file, and also lets
me wipe my swap file with Scorch as an extra precaution.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Security 7.0.3
Comment: My PGP Page & FAQ: http://www.McCune.cc
iQA/AwUBOtjzAQ2jfaGYDC35EQL4OgCgtPgznvL3TT4+N81jvx+2ol9BGRIAn2HD
DlgnYEuAka3/OLmv3Me2Bg5i
=/j1B
=====END PGP SIGNATURE=====
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
