Cryptography-Digest Digest #916, Volume #13 Fri, 16 Mar 01 13:13:00 EST
Contents:
Re: BBS ("Dobs")
Re: Encryption software ("Henrick Hellström")
Design Principles of Cryptographic Hash Functions (Jim Steuert)
Re: GPS and cryptography (br)
Re: ideas of D.Chaum about digital cash and whether tax offices are (George Weinberg)
Re: Is SHA Copyrighted? Can It Be Exported? (Bart Bailey)
Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long) ("Joseph
Ashwood")
Re: GPS and cryptography ("Joseph Ashwood")
Re: on-the-fly encryption ("Joseph Ashwood")
Re: PGP "flaw" ("Joseph Ashwood")
Re: How to eliminate redondancy? (Ichinin)
Re: NTRU parameters ("Dr. Yongge Wang")
Random and RSA (br)
Re: Noninvertible encryption (SCOTT19U.ZIP_GUY)
Re: Random and RSA ("Douglas A. Gwyn")
Re: Random and RSA (Tony L. Svanstrom)
Re: primes for Blum Blum Shub generator ("Joseph Ashwood")
Re: Secure overwriting ("Scott Fluhrer")
----------------------------------------------------------------------------
From: "Dobs" <[EMAIL PROTECTED]>
Subject: Re: BBS
Date: Fri, 16 Mar 2001 17:19:09 +0100
Thanx :))))))))))))))))))))))))))))))))))))))))))))))))))))
U¿ytkownik Joseph Ashwood <[EMAIL PROTECTED]> w wiadomo¶ci do grup
dyskusyjnych napisa³:ec$[EMAIL PROTECTED]
> What BBS needs is for the primes to be replaced before the modulus can be
> factored. This is generally harder to guess than it is to simply replace
> them for each new use.
>
> Lately I've found myself very often recommending the BIGNUM package in
> openssl (www.openssl.org), it's fast it's good, and it can generate those
> big primes for you with a single call, and can do so rather quickly.
> Joe
>
> "Dobs" <[EMAIL PROTECTED]> wrote in message news:9862va$mqp$[EMAIL PROTECTED]...
> > I have a question. How should good Blum Blum Shub Generator looks like?
I
> > know that it needs 2 large prime numbers p and q. Should this generator
> have
> > its own large prime number generator to generate new p and q each time
we
> > found our seed. Or it does not metter and I can for instance declare
that
> p
> > is such and q is such.
> > If it needs generator can somebody tell me one wchich would be proper
for
> > BBS, I mean will generate large prime numbers:
> > Best Regards:)
> > Michal
> >
> >
>
>
------------------------------
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Re: Encryption software
Date: Fri, 16 Mar 2001 17:20:21 +0100
"Joe H. Acker" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> I suppose that Henrick Hellström was refering to the fact that MITM is
> possible when Mallory has complete control over the channel used for
> initial public key distribution and over the message channel. Isn't that
> correct?
That's correct. The trust model does not prevent such attacks, because a
first public key has to be distributed sometime.
> But again, I don't know a protocol that would make
> communication secure in such an evil environment...or is there?
I don't think so, unless you transfer an initial shared secret by some other
mean, e.g. a public key on a floppy disk handed over in person.
------------------------------
From: Jim Steuert <[EMAIL PROTECTED]>
Subject: Design Principles of Cryptographic Hash Functions
Date: Fri, 16 Mar 2001 11:56:26 -0500
Design Principles of Cryptographic Hash Functions
I have gleaned the following from researching cryptographic
hash functions. Some of the most fascinating concepts of cryptography
(the Feistel concept and multipermutations) are embodied in the
modern hash functions like md4, md5, and sha-1.
I have not seen these principles presented in this "how-to"
summary manner in any book.
With a fair amount of effort, it should be possible to create
a large variety of hash functions based on these principles,
using these old and unpatented ideas.
Are there any major ideas that I missed?
1. A hash input block size is, say, n=512 bits, state is say, 160 bits
i.e. internal state size is the same as output bit size,
or in this case five 32-bit state words. (by convention a,b,c,d,e)
2. Each "compress" compresses the 512 bits into the state.
4. Each "compress" consists of multiple "rounds", and each round
consists of multiple "steps". Every step operates on the
state words, mixing in the input words. Many (>80) steps are
necessary
in order to diffuse and confuse the input data, and more importantly,
to thwart attacks by automated binary symbolic methods, as
in binary decision diagrams, etc.
5. With the input fixed, each compress/round/step is invertible, i.e.,
a final state can be used to derive an initial state of
the round (and thus the whole compress). This is the same
as a multi-permutation (or latin-square in a much smaller sense)
The purpose of this invertibility is not to run the hash backwards,
but to guarantee "balance", or statistical independence of the bits,
(see Bob Jenkin's article on "funnels")
6. Each step is feistel-invertible with a feedforward F function.
For md4, md5, and sha-1 it is bitwise on three of the state 32-bit
words.
It needn't be bitwise - that is only for efficiency.
The exact function F may vary depending on the round/step.
7. The F functions must be (0-1) balanced to not bias randomness.
For md4 these are:
f(x,y,z) = (x and y) or (notx and z)
g(x,y,x) = (x and y) or (x and z) or (y and z) (majority)
h(x,y,z) = (x xor y xor z) (parity)
For md5 these are:
f(x,y,z) = (x and y) or (notx and z) (multiplex)
g(x,y,z) = (x and z) or (y and notz) (multiplex)
h(x,y,z) = (x xor y xor z) (parity)
g(x,y,z) = (x or notz) xor y
For sha1 they are:
f(x,y,z) = x xor y xor z
g(x,y,z) = (x and y) or (y and z)
h(x,y,z) = (x or noty) xor z
i(x,y,z) = (x and z) or (y and notz)
j(x,y,z) = (x xor (y or not z)
If an F function is more than one bit in width, then
each column of the function output table must be 0-1 balanced,
it must satisfy SAC, be nonlinear, and pairwise independent.
All of the other s-box criteria should apply, because it is used
in a feistel sense. (see Tiger)
8. There may be multiple levels of feedforward. (as in Clapp)
9. Use addition/subtraction along with circular rotates
in order to create diffusion across bit positions, as
opposed to bitwise operators like xor etc which do
not diffuse across bit positions. (note failure of KHF)
10. Use a unique additive constant for each step.
11. 32-bit rotates of the state words are necessary
to eliminate low-order bit attacks due to additions/subtractions.
Optimize circular rotation amounts. (see MD5)
12. If expansion is used (as in sha-1) the expanded input
words must be a balanced function of the actual input words,
in order to preserve balanced-ness. Since balance is transitive,
across sub-permutations, the additional balanced rounds will
still be balanced.
for t=16 to 79, W[t] = ( W[t-3] xor W[t-8] xor W[t-14] xor W[t-16] )?
Does the cyclic nature of this guarantee that the output word bits
W[16-79] are a permuation of the input word bits W[0-15]
In other words, for sha1, could any balanced function be substituted
for the expansion formula?
References:
Optimizing a Fast Stream Cipher for VLIW, SMID, and Superscalar
Processors
by Craig S.K. Clapp
Evaluation Methodology for Security Primitives
by B. Preneel, B. Van Rompay, J.-J. Quisquater, H. Massias
Unbalanced Feistel Networks and Block-Cipher Design
by Bruce Schneier and John Kelsey
Tiger: A Fast New Hash Function
by Ross Anderson and Eli Biham
Analysis of Suitability for Pseudorandom BIST of the RC6 Cipher
by Erica Mang
Differential Cryptanalysis of KHF
by David Wagner
Proving that a hash has no funnels
by Bob Jenkins
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Fri, 16 Mar 2001 11:28:24 -0400
You have to use the position as second key to mix with another key.
You may reach key space 2^150 or more.
Joseph Ashwood wrote:
>
> Not very good. You would not have the actual of only being able to read the
> message from a specific locatin on earth, all you could do is use it to key
> a cipher. That is an important observation becase if you look at GPS, it is
> effectively 360 degrees, plus a few places of precision for each of two
> directions. Just to make things concrete, and use a planet large and more
> useful for this than earth, assume a perfect sphere of circumferance (sp?)
> 2^32 units, and a precision down to 2^-8 units. This is vastly better
> cryptographically than the earth, and it still fails for one very specific
> reason. In each direction there are 2^40 possible locations, this leads to
> only 2^80 security. 2^80 is the absolute minimum that is tolerable for
> security. Because this planetary GPS system is larger than that of earth it
> is safe to say that such a thing is not useful.
>
> There are several additional concerns, a persons general locatin on the
> planet it fairly common knowledge, for example there is no secret that I am
> in the Silicon Valley, in California, so there's only maybe 16-bits worth of
> variation to find my key under that system. I'm sure that similar statements
> could be made about you by someone who was interested in reading your
> e-mail.
> Joe
>
> "br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> > What do you think about using Global Positionning System (GPS) as key to
> > encryption?
> > You can read a message only if your computer is a pre-defined area or
> > point in the earth.
> > I'm waiting for comments
------------------------------
From: [EMAIL PROTECTED] (George Weinberg)
Crossposted-To: talk.politics.crypto,alt.cypherpunks
Subject: Re: ideas of D.Chaum about digital cash and whether tax offices are
Date: Fri, 16 Mar 2001 16:35:40 GMT
On Thu, 15 Mar 2001 19:43:16 -0500, John Christensen
<[EMAIL PROTECTED]> wrote:
>Thanks for the info, but it's not really exactly what I'm looking for.
>You see, I would like to have something similar to Deja, which
>is now defunct. It allowed me, with an account, to sit down at a
>terminal anywhere and post. So I could post from the library if
>I wanted.
>
>Remailers, as I understand, would require that I download a
>client program, and I of course can't do that at a remote location.
>
Technically you don't NEED the client program, it just makes
using the remailers a lot easier. You could, for example,
generate properly formatted messages at home and
store them on a floppy. All you need at the library
is a regular mail client (which you may or may not have).
George
>I suppose if there were any that would post unencrytpted
>submissions, I could do that -- ???
>
>
------------------------------
From: Bart Bailey <[EMAIL PROTECTED]>
Subject: Re: Is SHA Copyrighted? Can It Be Exported?
Date: Fri, 16 Mar 2001 08:10:11 -0800
Kent Briggs wrote:
> Bart Bailey wrote:
>
> > Now that an AES candidate has been selected, do you plan to incorporate it as
> > well as any of the others into Puffer?
> > I'm still using v3.11 and like the sda feature. Would like Rijndael and Twofish
> > if you ever upgrade.
> >
> > ~~Bart~~
>
> Both Rijndael and Twofish are at the top of my to-do list for Puffer. I don't know
> when that'll be however. I'm currently working on an upgrade for Directory Snoop.
I have the v3.00 for that but have to admit that it isn't as intuitive as Recover4all
[http://www.recover4all.com/] in recovering deleted files. Also Eraser
[http://www.tolvanen.com/eraser/] works much faster and simpler for removing filename
references.
Not trying to base on your product, just a couple of observations from a casual user.
Maybe if I understood all the arcane FAT information that Directory Snoop displays, I
could better utilize its features.
~~Bart~~
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Cipher Idea #1 Block Cipher 512-bit block, arbitrary keysize (long)
Date: Tue, 13 Mar 2001 11:34:17 -0800
Correcting some errors.
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:#lBs0C4qAHA.340@cpmsnbbsa09...
> Encrypt(inputBlock, numRounds)//inputBlock is 512-bits arranged in OCTETs
> //all addition is done modulo 8 to avoid going outside the bounds of the
> array
should read
All array indexing is done modulo the size of the array
> Space requirements:
> be doable at about the 10k transistor level, which would make it one of
the
Is incorrect, I believe that outside of the space needed for the RAM for the
sboxes, it can be done in 10k transistors, the RAM for the Sboxes will take
~24k additional. This will still make it smaller than many of the smaller
block ciphers done in parellel hardware.
> I await the traditional slaughter of the cipher. Just a reminder this is a
> curiosity cipher, I have little expectation that it will be secure.
Is still true.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: GPS and cryptography
Date: Tue, 13 Mar 2001 11:54:01 -0800
Actually Rabin's latest method requires true random numbers. The GPS system
uses signal + pseudorandom variance. There has been some discussion in some
circles that the pseudorandom variance may now be set at 0, but I'm unsure
about tha actual state of this. Regardless the fact that it is pseudorandom
eliminates it's effectiveness, the only randomness left would be your exact
position on the planet which is not entirely random.
Joe
"ObiTwo" <abuse@localhost> wrote in message
news:[EMAIL PROTECTED]...
> On Mon, 12 Mar 2001 21:02:29 -0400, br <[EMAIL PROTECTED]> wrote:
>
> >What do you think about using Global Positionning System (GPS) as key to
> >encryption?
> >You can read a message only if your computer is a pre-defined area or
> >point in the earth.
> >I'm waiting for comments
>
> This is not about the original subject of the thread, but about a
> lateral thinking: isn't the data stream from a GPS satellite a
> pseudorandom sequence of bits? If I remember correctly, it is so. In
> this case, couldn't one use it as the source of pseudorandom bits for
> Rabin's latest "unbreakable" cryptographic scheme? Of course, one
> would have to trust that the sequence is really pseudorandom, which as
> far as I understand cannot be demonstrated from the sequence alone.
>
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: on-the-fly encryption
Date: Tue, 13 Mar 2001 12:01:43 -0800
There are several possibilities. Some systems will simply decrypt the entire
file and store it in memory. Some will actually store a decrypted version on
disk (bad idea). But the most security aware become a disk. A disk is
accessed not on the basis of files, but on the basis of blocks, a contiguous
block is of some generally fixed size per drive. A single block will be
accessed, that block will be decrypted, when it is written that block will
be encrypted.
Of course there's always exceptions to this, and people will find various
ways to destroy the security they so loudly claim so I'd recommend you
choose a well-respected system.
Joe
"%NAME%" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi encryption experts,
>
> I apologize in advance if this message appears twice, because I tried
> posting this once already and it didn't seem to work.
>
> I am a newcomer to cryptography, and I have a question about on-the-fly
> encryption. Many software programs claim to provide on-the-fly
> encryption services, where encryption/decryption of a file is done
> automatically when a file is accessed.
>
> I have a question regarding this concept:
>
> 1) When a file is accessed and on-the-fly encryption is used, where is
> this file stored while I'm using the file? In memory somewhere? What
> if the file is large? The file must be decrypted during use, but it
> cannot be stored in the hard disk, or that would defeat the purpose of
> on-the-fly encryption.
>
> Any reponses will be greatly appreciated.
>
> Thank you,
> Betty
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: PGP "flaw"
Date: Tue, 13 Mar 2001 17:16:27 -0800
I assume you mean the ADK bug.
Anyway, encryption is to keep the unauthorized from reading the information.
As far as I'm concerned my employer is permitted to read anything I
send/recieve at work, but then again if I'm going to hide truly hide
something I'm not going to do it through encryption, I'll do it through
complete lack of information. As to why I use PGP to/from work/home, some of
the information that is distributed through that channel may amount to
unreleased technology, I would decrypt it for the proper authority, given a
suitable reason ("I wanna see it", is generally not a suitable reason), they
just never ask.
Now about your apparent misunderstanding of what this bug is. It is not a
back door, it is not a flaw in the "public key method," it is not a flaw in
the methodology, it does not compromise past messages, and it's detectable
(some of those are from other debates at the time, not necessarily from
you). It is a flaw in the key verification. At the time it first came to
light there were several public announcements that none of the pgp keys on
the various key servers seem to have been subject to an attack based on
this. In had no effect on me as my important keys are kept extremely secure,
with old (personally certified) copies replacing the current information
after reasonable time periods (I chose a week). I'm willing to answer more
questions regarding how I use PGP, and how I've avoided the pRNG flaw, and
the ADK flaw, if you'd care to e-mail me privately. Basically if you use PGP
(or any other secure e-mail system) properly you are protected against minor
flaws in the system.
Joe
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How to eliminate redondancy?
Date: Tue, 13 Mar 2001 22:18:38 +0100
br wrote:
>
> It will reduce little bit a redundancy. So compression is better.
> Is there any other way other than compression. That's my question.
How about a keyed permutation algorithm that shovle
bytes around? It's easy to write one in under 15
minutes, or adopt one (i.e. RC4) to do the flipping,
then apply regular crypto on top and finally a layer
of sugar, then we eat it :o)
Regards,
Ichinin
------------------------------
From: "Dr. Yongge Wang" <[EMAIL PROTECTED]>
Subject: Re: NTRU parameters
Date: 16 Mar 2001 17:14:29 GMT
Colleen Marie O'Rourke <[EMAIL PROTECTED]> wrote:
: Hello :)
: I am writing to anyone who knows about the NTRU cryptosystem. I have a
: couple of questions.
: 1) The parameter, p, is supposed to be relatively small compared to q.
: But, what if p was close to q but they were still relatively prime to each
: other? How would that affect the security? Which attacks would NTRU be
: most vulnerable to as a result?
I guess then you can never decrypt a message correctly:-)
this is not related to the security rather related to the errors.
For NTRU cryptosystem, for certain probability, the recipient
cannot decrypt the correct message. If p is large, the probability
will be quite high.
: 2) For p=3, the coefficients for the random polynomials should be either
: 1, 0, -1 where the sample samples Lf, Lg, Lphi determine the #1's and #
: -1's. If p was chosen to be something other than 3, how would this affect
: the coefficients of the random polynomials? Would they still be only 1,
: 0, -1 or would they be -p/2 to p/2? How would this affect the user
: defined sample spaces (Lf, Lg, Lphi)?
it would then be -p/2 to p/2. User defined sample spaces? get ready
to be broken soon:-)
These sapces are carefully chosen by some statistical test.
If you do not choose carefully, the schema might be broken
easily:-)
Yongge
: If anyone could clear up these questions, I would be most appreciative :)
: Thanks, Colleen
: :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o) :o)
=========================
Yongge Wang
http://cs.uwm.edu/~wang/
=========================
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Random and RSA
Date: Fri, 16 Mar 2001 12:12:51 -0400
Factoring N is it so hard?
If the use of pseudorandomness function is not secure, why RSA is seen
as secure. When you multiply two prime big numbers, the operation is not
random? P has a sequence of digits that is non ramdom, Q too.
So I don't understand?
If someone can break a pseudo-random function, why can't he break a
deterministic function?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: 16 Mar 2001 17:18:36 GMT
[EMAIL PROTECTED] (Douglas A. Gwyn) wrote in <[EMAIL PROTECTED]>:
>"SCOTT19U.ZIP_GUY" wrote:
>> [EMAIL PROTECTED] (Paul Crowley) wrote ...
>> >But there's no real security issue since our ciphers are designed to
>> >resist known-plaintext attack.
>> I like the disclaimer "know-plaintext attack" Unfprtunatately
>> its the plaintext attack that you don't know about when you use
>> a method that ends up bitting you in the ass.
>
>Do you really not know that in a "known-plaintext attack" it is
>the plaintext that is known, not the attack?
Maybe its my dslexia showing showing through. I know that
the plaintext and ciphertext are known in the attacke. What
I was trying to point out was that one can never know if it
a cipher is resitant to such attacks just becuase one seems
unable to find an attack that seems to work for a given cipher.
I was refering to the methods as being known or not known
>
>> ... The closed minded belief is that compresion headers are the
>> only problem and not the general structure of the output file.
>> Well they are wrong.
>
>It would be useful to explain why, because it certainly appears that
>a compressed file has less structure "everywhere" except near the
>beginning where not only might there be a header but also the
>dictionary is being filled at a rapid rate.
>
I wish you could get Matt Timmermans to jump in here. Since
he is one of the few who understands what I mean. Though he makes
no claim that it improves security. But he fully understands
the concpet of no added information. I gues about the only
thing I can do is repeat what I have said before.
If a compression system that compresses "FILES" not streams so
I don't get in an argument with the KING compressed file to
a binary set of files. I prefer 8-bit byte files but you could
use a special compressor that aways compresses to some fiexed
block size like 128 bit multiples. Any way if you allow
the bits in this output file be any set of bits possible.
Does this file decompress to a unique file that when compresses
goes back to this set of bits. If the anwser is no then
the compressor is adding wasted information to the file.
There may be many ways to extract this added info.
One such way is if an ememy tries to crack your encryption
and tests a key. He uses key to cehck what happens when
he decrypts and decompresses the file. With most garbage compression
systems in use. The compress part will either fail to decompress
or if it does. When you try to recompress you don't get the same
file back. This is giving information that the key tested was bad.
However if you used a compression system that works like BICOM
you don't get this sort of problem,
I am trying to post another sample that uses several compressors
in a batch program that adds no information to a file yet allows
one to encrypt an arbitary set of files of symbol set one to
symbol set two in a 1-1 way.
SEE
Proper use of Rijndael with subsets
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Random and RSA
Date: Fri, 16 Mar 2001 17:28:47 GMT
br wrote:
> Factoring N is it so hard?
> If the use of pseudorandomness function is not secure, why RSA is
> seen as secure. When you multiply two prime big numbers, the
> operation is not random? P has a sequence of digits that is non
> ramdom, Q too.
> So I don't understand?
> If someone can break a pseudo-random function, why can't he break a
> deterministic function?
You seem to seek a shortcut to knowledge. However, there is a lot
more to cryptology than simply thinking "random <=> secure". In
the case of RSA, the system can *in principle* be cracked, but the
best ways anyone has thought of to attack it, apart from a small
number of special cases, are equivalent to finding the prime
factors. For large numbers, *this is hard* using even the best
known techniques. (RSA's Web site has some large products-of-two-
primes that you can win money by factoring, if you want to try.)
If the best known attacks against a system require more computation
than is available, in order to have an appreciable chance of success,
then the system can be considered secure, except possibly against
attacks we do not yet know about.
There is no single method for inverting all encryption functions,
so the ability to crack some PRNGs does not necessarily imply that
one can break all other deterministic systems.
------------------------------
Subject: Re: Random and RSA
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Fri, 16 Mar 2001 17:33:04 GMT
br <[EMAIL PROTECTED]> wrote:
> Factoring N is it so hard?
Try it!
/Tony
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: primes for Blum Blum Shub generator
Date: Wed, 14 Mar 2001 11:45:37 -0800
You only need to change them periodically (the decision of how long to wait
is complex, but if you use it as a stream cipher you only have to change
when you rekey). The algorithm to generate huge primes goes like this:
pick a random number R of the right size, make sure it's odd
while(NOT(israndom(R))
add 2 to R
end while
programming israndom is a complex task, and I would recommend simply using
something like openssl for that part. Of course openssl also has functions
to generate primes.
Joe
"Dobs" <[EMAIL PROTECTED]> wrote in message news:98o5qk$9cc$[EMAIL PROTECTED]...
> Hello,
> I am trying to implement Blum Blum Shub generator. I need 2 large prime
> numbers p and q. Where should I take this numbers from,( I gess each time
> they generate one bit, they have to be changed) Is there any algorithm
to
> obtain such a large primes, which would be right for BBS generator.
> Thanx, best regards
> Michal
>
>
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Secure overwriting
Date: Fri, 16 Mar 2001 09:24:30 -0800
Eric Lee Green <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 15 Mar 2001 03:52:21 +0000, David Hopwood <[EMAIL PROTECTED]>
wrote:
>
> >The OS should support erasing a file, and/or marking a file as
> >'sensitive' as a system call, which should tell the driver(s) to
> >do the right thing at the IDE/SCSI/whatever level. Also, the virtual
> >memory subsystem should be designed to allow secure overwrites of
> >sensitive memory blocks. That's the only way to reliably ensure that
> >data can be erased.
>
> Ooof! I forgot about the swap file! Ouch. That's another ball of wax.
> Whoosh.
Actually, I'd think that swap files would be pretty easy to handle, at least
if you have OS sources. All you need to do is, at boot up time, select a
random (say) AES key to encrypt any data written to, and read from, the swap
file. The key never needs to be written anywhere, and once you have powered
down, the data is unreadable. Next time you boot up, the system selects a
different key. The only problems I can see are:
- The problem of gathering enough entropy to select a good key at boot-up
time is rather more difficult than I implied. I suspect it might still be
doable.
- You can no longer save crash information in the swap partition.
--
poncho
------------------------------
** 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
******************************
