Cryptography-Digest Digest #367, Volume #10 Wed, 6 Oct 99 05:13:03 EDT
Contents:
Re: factoring with quadratic sieve (jerome)
Securing Windows 95 Swap/Temp Files (long) ([EMAIL PROTECTED])
Re: radioactive random number generator (jjlarkin)
Re: radioactive random number generator (Boris Kazak)
Re: EAR Relaxed? Really? (Greg)
RSA Cryptography Today FAQ (1/1) ([EMAIL PROTECTED])
Re: Random number generation ("Richard Parker")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (jerome)
Crossposted-To: sci.math
Subject: Re: factoring with quadratic sieve
Reply-To: [EMAIL PROTECTED]
Date: Wed, 06 Oct 1999 02:07:03 GMT
The poster tries to find a library which have it and let him access
to it. If somebody had a online copy, it would have been a waste
of time to visit the local libraries, a time precious because i am
just an amateur. So i still think my question was suitable.
Thanks for your offer but i will use it only if i don't find locally
a local copy.
On Tue, 05 Oct 1999 14:44:37 GMT, Bob Silverman wrote:
>
>Note that I also offerred to *send* a hard copy if only the poster
>would send private email with his/her snail mail address. So far, I
>have heard nothing further. This tells me that the person involved
>really isn't that interested.
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Securing Windows 95 Swap/Temp Files (long)
Date: Wed, 06 Oct 1999 03:17:52 GMT
Hello fellow sci.crypters,
I have been doing a survey of encryption products
for the Windows operating system. Many fine
products are available but none address the
problem of plain text leaking. The most obvious
examples of plain text leaks are the virtual
memory swap file and temporary directories. Many
other leaks exist as well e.g. INI files often
contain sensitive information. As long as plain
text leaks, an attacker may gain information about
secure files or even a key(s) via the swap file.
I am interested in security when the computer is
OFF, BTW. So far as I can tell, if someone can
access your computer while it is on and logged in,
then no products are secure. Hardware or
operating system help would be required for
the on-line scenario.
To have confidence in an encryption product on a
Windows machine:
1. All sensitive files must be strongly encrypted
perhaps via a virtual hard drive
2. All temporary files must be strongly encrypted
perhaps via a VXD
3. All configuration files must be strongly
encrypted perhaps via VXD.
I have designed and partially written a solution
for steps 2 and 3.
Step 1 can be accomplished by placing all
sensitive apps and data on a virtual disk e.g.
BestCrypt NP, ScramDisk, etc. Now if temporary
and configuration files can be encrypted, Windows
should be much more secure.
Here is my design for a VXD/GUI combination to
solve steps 2 and 3 under Windows 95. I would
like interested members of this group to look at
the security of the design. I intend to release
the software into the public domain as freeware.
If I put a huge amount of work into it I may
release a professional shareware version.
The tentative name of the app is Avalanche. The
block cipher is Twofish and the PRNG is Yarrow
both thanks to the brains at Counterpane. I just
happen to like Twofish, any other 128 bit cipher
would work. I am using the VxdWriter toolkit. The
toolkit is quite useful and low priced. I have
borrowed knowledge and code from the FileMon
utility from Sysinternals.
VXD design
The VXD has following requirements:
1. Intercept all I/O between windows and the
files/directories/process in question
2. Strongly encrypted/decrypted I/O in real time
3. Impose a minimum performance penalty on the OS
4. Securely generate and store new keys for new
files
5. Securely handle keys for all ready encrypted
files
6. Robustly watch for errors to avoid data
corruption
7. Avoid reentrancy into Win 95 IOS
I have already written most of this part. It
seems to be working well but needs polishing.
Currently all keys are read in at start up time,
this takes up quite a bit of memory.
Here is how is works:
1. At startup one key for each encrypted file is
read into (non-paged) memory and decrypted using a
master key. The master key is generated from the
users pass phrase.
2. As files are opened, they are check against a
list of directories to encrypt. I want to support
file and process level encryption as well. The
swap file is encrypted.
3. When a file is read/written is key is retrieved
from the internal list.
4. The swap file is encrypted with a one time
session key. Nobody may look at it after
shutdown.
5. The files are encrypted/decrypted as follows:
The block offset is determined by the file offset
div 16 (128 bits)
The byte offset is determined by the file offset
mod 16
Twofish is initialized with the key
The block number is transformed into a 16 byte
string and encrypted. This is an example of
Counter Mode.
The plain text is XOR with the byte offset of the
encrypted block.
6. When a file is created, a new key is generated
using the Yarrow PRNG. A 256 bit is generated.
The effective key length is 160 bit because of the
Yarrow implementation. I think 160 bits is better
than 128 however so 160 it is. A separate key is
generated for each file. This is a must with a
counter mode encryption algorithm.
7. When a file is deleted, the key is removed from
memory.
8. On exit, all keys are written back out using
Twofish with the master pass phrase. This part
needs improving for crash situations. The keys
should be written out more often. Additionally,
the keys should be split up by directory or some
other index tree. A key backup and/or an
administrator key should be added.
9. No IOS reentrant calls are needed because all
keys are in memory and each byte can be
encrypt/decrypted without knowledge of any other
byte.
The GUI portion will gather the master pass phrase
at startup. Additionally, the GUI will allow
directories/files/process to be designated a
encrypted/plaintext. I want to add pass phrase
analysis to -only- allow strong phrases.
Any thoughts,
Please email any replies as well as posting.
thanks,
--Matthew
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jjlarkin <[EMAIL PROTECTED]>
Subject: Re: radioactive random number generator
Crossposted-To: sci.electronics.design,sci.electronics.equipment
Date: Tue, 05 Oct 1999 21:43:22 +1700
Any resistor at room temperature generates wideband (Johnson) noise. A
50 ohm resistor generates just about 1 nanovolt times the square root
of the measurement bandwidth. This isn't much noise, so it has to be
amplified a lot.
To generate a simple encryption key, or a few random numbers, is easy.
Just spin a counter until somebody hits a key, and you're done. It's a
lot harder to generate a high-speed stream of random bits or numbers,
especially when you need low autocorrelations and/or a lack of
'breakable' structure to the random numbers.
The thermal resistor noise has this problem: for high data rates, you
need a wideband amplifier, and the amplifier will add its own noise,
including 1/f (flicker) noise, popcorn noise, power supply ripple, and
other statistically nasty stuff. A bigger resistor gives more noise to
work with but then stray capacitance will limit the bandwidth, hence
the rate at which you can extract statistically good noise.
The zener diode is great: it has a high noise density (about 300x that
of a 50 ohm resistor), gausian distribution, and a low impedance. All
that makes it easy to amplify without wrecking the statistics.
John
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Crossposted-To: sci.electronics.design,sci.electronics.equipment
Subject: Re: radioactive random number generator
Date: Tue, 05 Oct 1999 21:56:41 -0400
Reply-To: [EMAIL PROTECTED]
John E. Kuslich wrote:
>
> Actually, the idea is brilliant!!
>
> Even better, feed the thermal noise into an oscillator driven by a strange
> attractor or other chaos mechanizm.
>
> The effect is like thousands of Bejing Butterflies. We are talking hurricanes
> in Miami!!
>
> JK
===================
The idea is very practical - imagine the VCO running at 5MHz +/- 10%
and the sampling done each 10 microseconds. The flip-flop will change
its state 50 times +/- 5 times between the samplings, and you have
absolutely no way of telling, will it be an even or odd number of
reversals. Couple this to the serial port and collect random bits at
the rate of 100 Kbit/sec, (or maybe you need faster?)
BTW, the serial port in full-duplex mode can provide the clocking
for sample collection.
Best wishes BNK
=======================
>
> John Larkin wrote:
>
> > Boris Kazak wrote:
> > >
> > > jjlarkin wrote:
> > > >
> > > > Radioactive decay is not only messy to implement, it produces a random
> > > > pulse train, hardly suitable for turning into nicely distributed
> > > > gausian noise.
> > > >
> > > > A zener diode is a great noise generator. Bias a 10-volt zener at about
> > > > 0.5 ma, and you'll get nice wideband noise across it. Amplitude will be
> > > > about 300 nv per root Hz (300 nv times the square root of the bandwidth
> > > > of the following amplifier). If the amp has a decent highpass response
> > > > (ie, cut out low-frequency 1/f noise) the result will be excellently
> > > > random gausian noise with very low autocorrelation for reasonable
> > > > sample rates. Just digitize it, or slice it and clock into a shift
> > > > register.
> > > >
> > > > If you want perfect 1:0 balance and even lower autocorrelation, stir
> > > > the zener's random output into the guts of a pseudo-random shift
> > > > register.
> > > >
> > > > easy!
> > > >
> > > > John
> > > -----------------------
> > > And one more elegant idea - feed the output of this Zener diode
> > > into a Voltage Controlled Oscillator, feed the output of this VCO
> > > into a flip-flop, and at any time when needed sample a random bit.
> > >
> > > Best wishes BNK
> >
> > Boris,
> >
> > actually, that would probably increase the autocorrelation, since the
> > VCO will tend to oscillate about an average frequency.
> >
> > John
> >
> > --
> > ******************************************************************h
> >
> > John Larkin, President phone 415 753-5814 fax 753-3301
> > Highland Technology, Inc
> > 320 Judah Street [EMAIL PROTECTED]
> > San Francisco, CA 94122 http://www.highlandtechnology.com
------------------------------
From: Greg <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: EAR Relaxed? Really?
Date: Wed, 06 Oct 1999 05:04:07 GMT
> > You mean persons with PRINCIPLES, not
> > agencies constituted as SECRET POLICE.
> Law enforcement officers, of whatever branch, are people
> just like everyone else on the street. The vast majority
> of them are decent, hard-working people who are just
> trying to do a very difficult job. To characterize all
> the good ones as unprincipled, immoral, or evil is just
> a wrong as ignoring or failing to hold accountable those
> few who are.
Those "many" you refer to will continue to violate our highest
law because they will be told it is correct to do so- so much
for characterizing.
Until they stand up against the corrupt leadership and say,
"Hell, no! We won't follow that unconstitutional order!",
they ARE Karl's very worse nightmare come to life.
Don't knock what he is saying. He is correct far more than
you care to admit.
--
Truth is first ridiculed, then violently opposed, and then it is
accepted as self evident ("obvious").
I love my president... I love my president... I love my president...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
Subject: RSA Cryptography Today FAQ (1/1)
Date: 6 Oct 1999 07:49:56 GMT
Reply-To: [EMAIL PROTECTED]
Archive-name: cryptography-faq/rsa/part1
Last-modified: 1997/05/21
An old version of the RSA Labs' publication "Answers to Frequently Asked
Questions about Today's Cryptography" used to be posted here until May
1997. These postings were not sponsored or updated by RSA Labs, and
for some time we were unable to stop them. While we hope the information
in our FAQ is useful, the version that was being posted here was quite
outdated. The latest version of the FAQ is more complete and up-to-date.
Unfortunately, our FAQ is no longer available in ASCII due to its
mathematical content. Please visit our website at
http://www.rsa.com/rsalabs/ to view the new version of the FAQ with your
browser or download it in the Adobe Acrobat (.pdf) format.
RSA Labs FAQ Editor
[EMAIL PROTECTED]
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Random number generation
Date: Wed, 06 Oct 1999 07:47:32 GMT
"j.w.altena" <[EMAIL PROTECTED]> wrote:
> At Statistics Netherlands (SN) we have a project called the "virtual
> census". For this project we combine al the individual data on persons we
> have at SN. This individual data is from registrations and surveys. At the
> end this (yearly and probably longitudinal) virtual census will comprise all
> the data of 16 million dutch, their jobs, households, houses, social
> benefits, etc.
>
> Due to our privacy regulations we must split as soon as possible the so
> called identifiying variables (address, zip-code, etc) from the statistical
> variables (age, wages,etc). Some people of my staff are allowed to work with
> only the identifying variables (staff which are responssible for linking the
> individual data form different sources), others with only the statistical
> variables. A very limited part of my staff is allowed to work - only for a
> limited time - with both groups of variables. They must assign the
> identifying numbers.
>
> We need this identifying numbers for the following:
> When we get a file with the individual data we assign to each record a two
> unrelated unique - identifying - numbers. One of them is not a number from
> 1 to N because that could - at a some stage - give some information. Then we
> split the file in three parts: one part with at each row only the two unique
> numbers (the linking-table). One part with at each row one unique number and
> the identifying variables (the identifying part) and ond a part with the
> other unique number and the statistical variables (the statistical part). My
> staff is only granted rights for the part they need te use for their job. In
> this manner it isn't possible to get access to the statistical data when you
> have access to the identifying data, v.v. Then we sort the three files on
> their (first) indentifying number. To be more secure, we enrypt the
> linking-table so that it's impossible for our automation-staff to link the
> data as well. When we need tot combine the two groups of variables, we can
> use the linking table to do this (to do that, we need a lot of signatures).
> So we need a lot of unique ("random") numbers of a the specified size, may
> be this explanation give you some help.
>
> One remark: One could also assign one unique number and use an encryption of
> that number as a second number. We rejected that idea because it leans on
> the "security" of the encryption algorithm. This security may be good as
> this moment, but we need a procedure which will last for at least fifty
> years or so
Jan,
As I understand it, you want a mechanism for defining a system that
implements a secure relation between identifying variables and
statistical variables. Furthermore, you expect at least 16 million
(2^24) entries in the relation and the entire system needs to be
secure for at least fifty years.
You also mentioned at the start of this thread that you wanted the
identification numbers to be 10 digit numbers (presumably to fit in a
fixed database field). You didn't mention if the identification
numbers used for the identifying data had to be guaranteed to be
unique from the identification numbers used for the statistical data.
If they have to be unique then an adversary who knows an ID for
statistical data knows that this value is not a valid ID for the
identifying data. Even if the two sets of ID numbers do not have to
be unique from each other, it is still a good idea to deny the
adversary the ability to distinguish each set from a random set of
numbers. Since you expect to have about 2^24 people in your data, you
will have to assign either two sets of 2^24 or one set of 2^25 unique
numbers. In order to deny the adversary any information, the unique
numbers should be come from a set of at least 2^48 numbers (1.2 *
(2^24)^2 ~= 2^48) by the birthday problem. This suggests that the
identification numbers should be about 15 digits long.
1. Requirements
Clearly the system can be considered compromised if an adversary can
recover a person's identifying variables given the person's
statistical variables or the reverse. However a system that is secure
against this kind of compromise is probably not sufficient. Consider
an adversary who can recover a single random valid variable pair for
which he lacks authorization. The adversary can use this information
to discredit the security of the system, even if he lacks the ability
to break the system in general. So the system should be secure even
against this weaker form of compromise.
Next, consider what kinds of information the attacker is able to use
in his attempt to compromise the system. I think that the system
should be designed to be secure against an adversary who has, at the
very least, the following information:
1. A complete list of all of the identification numbers for the
identifying variables.
2. A complete list of all of the identification numbers for the
statistical variables.
3. A few valid identifying/statistical pairs.
2. Systems
I'll use the following terminology for discussing this system:
N the number of people
A identification number for a person's identifying variables
A_i identifying ID number for i'th person
B identification number for a person's statistical variables
B_i statistical ID number for i'th person
K secret key
E encryption function
E_K encryption function keyed with key K
D decryption function
D_K decryption function keyed with key K
R source of true random numbers
Let's consider the security of several different schemes of forming
the secure relation between A and B.
2.1 Encryption
First, you mentioned that you've already considered assigning a unique
number for A and then encrypting A to form B, as follows:
1. K = R
2. A_i = i
3. B_i = E_K(A_i)
The security of this scheme relies on keeping the key K secret and the
fact that E can not be computed without K. You mention that you've
rejected this scheme because of your concern that the encryption
function E can be attacked to recover K. So, for the rest of this
discussion I'll grant the adversary the ability to break an arbitrary
encryption function E to recover the key K.
A slight variation on this scheme uses two keys:
1. K1 = R
2. K2 = R
2. A_i = E_K1(i)
3. B_i = E_K2(A_i)
This scheme isn't intended to be any stronger than the first scheme,
but it has the advantage that the position of an A_i in the list of
A's is less obvious.
2.3 Random Table
You are currently evaluating schemes that replace the encryption with
a relation implemented as a random table. The ideal implementation of
this scheme would use require more than 2^30 (2 * 2^24 * 24) bits of
true random data, as follows:
1. A_i = R
2. B_i = R
The security of this scheme relies on keeping the entire table (A,B)
secret and the fact that R is a source of true random numbers.
Like any of the other schemes, you have to make sure that all possible
lists of A or B that are available to your adversary are never in the
same order in which A and B appear in (A,B) otherwise the attacker can
reconstruct the table (A,B).
2.4 Table Generated Using Encryption
At the beginning of this thread you mentioned that you are currently
considering a variation of the table scheme that uses an encryption
function to generate the table as follows:
1. K = R
2. A_i = E_K(i)
3. B_i = E_K(i + N)
The adversary can attack this scheme to recover A_i from B_i by
breaking E to recover K, decrypting to find i+N, subtracting N, then
encrypting i to compute A_i.
You might try strengthening this scheme by:
1. K1 = R
2. K2 = R
3. A_i = E_K1(i)
4. B_i = E_K1(i + K2)
It however, is no stronger than the first scheme. The adversary who
knows a single (A_j,B_j) pair can attack this scheme to recover A_i
from B_i by breaking E to recover K1, decrypting A_j and B_j to find j
and j+K2, subtracting j from j+K2 to find K2, decrypting B_i to find
i+K2, subtracting K2 from i+K2 to find i, then encrypting i to compute
A_i.
A better strategy might be:
1. K1 = R
2. K2 = R
3. A_i = E_K1(i)
4. B_i = E_K2(i)
However, an adversary who an break E can break this scheme as well.
In fact any scheme that builds the table using encryption (or for that
matter any pseudo-random number generator) can be broken by breaking
the underlying encryption.
3. Conclusion
I think that you should either use encryption directly to map between
the ID numbers for the identifying variables and the ID numbers for
the statistical variables or use a hardware source of true random
numbers to construct your mapping. Using encryption has the advantage
that the secret you have to keep secure is much smaller, presumably in
one of the tamper-proof hardware devices specifically designed for
keeping encryption keys secure. Using a secret table constructed
completely by using true random numbers has the advantage of not
relying on encryption for security. I suggest that you should
consider asking a cryptographer for advice. I even know of a
well-known cryptographer who resides in the Netherlands. Since his
own privacy is going to be affected by your system, it seem likely
that he would be willing to provide you with some advice. The
researcher is Dr. Henk van Tilborg of Technische Universiteit
Eindhoven. His home page is at the following URL:
<http://www.win.tue.nl/math/dw/personalpages/henkvt/>
I recommend you contact him for advice.
-Richard
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
