Cryptography-Digest Digest #838, Volume #8 Mon, 4 Jan 99 06:13:03 EST
Contents:
Prime Gaps: a method for calculating them. ([EMAIL PROTECTED])
Re: RSA-Broken!!! ("Trevor Jackson, III")
Visual Basic Cipher ("CYFer")
ZIP encryption safe? (http://come.to/Delphi-Box)
Re: ZIP encryption safe? (http://come.to/Delphi-Box)
Re: Generating random numbers (was Re: Secretz revisited) ("Thomas J. Boschloo")
Re: ZIP encryption safe? ("~Mike Turco")
Re: Visual Basic Cipher (Brad Aisa)
Generating random numbers (was Re: Secretz revisited) ("Thomas J. Boschloo")
Re: Opinions on S/MIME ([EMAIL PROTECTED])
Re: PGP Keys on Smartcard (Bill Ray)
Re: Opinions on S/MIME ([EMAIL PROTECTED])
Re: Help (How long can a post be seen?) (fungus)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.lang.apl,sci.math
Subject: Prime Gaps: a method for calculating them.
Date: Mon, 04 Jan 1999 02:07:59 GMT
The following is a first draft program (written in J notation,
http://www.jsoftware.com) that generates prime numbers from prime gap
calculations.
The algorithm is initialized with the first prime number, 2, and the first
prime gap, 1. It adds the two values to obtain the next prime number, 3,
and, with it, calculates the next prime gap, 2. It adds the latter two
values to obtain the next prime number, 5, and, with it, calculates the next
prime gap, 2. It adds the latter two values to obtain the next prime number,
7, and, with it, calculates the next prime gap, 4. And so on.
With unlimited resources, the algorithm would continue the above process,
endlessly, generating all prime numbers from all prime gaps. This algorithm,
however, uses too many resources to be of practical use. With every new
prime number, p, the algorithm calculates a sequence of numbers, which can be
cumulatively added to the prime number, over and over, to generate all
relative prime integers to p. The number of values in the sequence grows
primordially. As if that weren't enough to render the algorithm impractical,
the algorithm must also keep track of a multidimensional, spatial location
for the values in the sequence. Algorithms based on the method behind this
one should have to simplify both those aspects of this implementation to
obtain any practical use for the methodology.
At any step, the first value in the sequence will always be the prime gap to
the next prime number. The algorithm generates all prime gaps, and all prime
numbers, only using sums and multiplications; it does not use division,
subtraction, or even conditional statements. A sort function was used to
expedite programming, so conditional statements are being performed by that
function, although use of a sorting function is not inherent to the
algorithm.
For those unfamiliar with J notation, any text following "NB." is descriptive
text.
As always, related questions and comments -- especially criticisms -- are
welcome.
torres
Torres' Prime Gaps Generator
NB. Initialize variables useful to user gap=: 1 NB. always a prime gap;
eventually every prime gap. prime=: 2 NB. always a prime number; eventually
every prime number. gapstr=: 1 1 NB. always a vector of integers. All
numbers relatively prime to numbers < PRIME are produced by cumulatively &
repeatedly adding GAPSTR to PRIME.
NB. Initialize internal use variables
idxstr=. 0 1 NB. always a vector of integers; same shape as GAPSTR
locstr=. 0 0 NB. always a vector of integers; same shape as GAPSTR
gaps=: 2$1 1 NB. always an array of integers; increases dimension every
iteration. Spatial arrangement of values in GAPSTR.
locs=: 2$1 0 NB. always an array of 1s and 0s; same shape as GAPS. Spatial
locations of values in GAPS to be processed, next.
NB. Begin definition of function to be repeated, over and over
repeat=: 3 : 0 NB. every call of repeat generates a new prime gap, new prime
number, and new list of relative prime gaps.
NB. next prime gap
gap=: {. gapstr NB. first element of GAPSTR.
NB. next prime number
prime=: prime + gap NB. old PRIME plus new GAP.
NB. calculate new relative prime gaps, spatially
gapstr=: (0&~: # ]) ,gaps NB. non-zero elements of GAPS, (i.e., all values
past last zero in GAPS)
idxstr=. ($gapstr){. \: 0~: ,gaps NB. indices into GAPS of values in gapstr.
locstr=. idxstr{ ,locs NB. marks corresponding to values in gapstr.
gapstr=: gapstr+ 1&|. locstr*gapstr NB. add those values from GAPS marked by
LOCSTR to previous, adjacent values in GAPS.
gapstr=: gapstr* -.locstr NB. set those values in GAPS marked by LOCSTR to
zero.
gaps=: ($gaps)$ gapstr idxstr } ,gaps NB. amend GAPS with new relative prime
gaps
NB. convert relative prime gaps to non-spatial string
gapstr=: (0&~: # ]) ,gaps NB. non-zero elements of GAPS, (i.e., all values
past last zero in GAPS)
NB. redimension spatial representation of relative prime gaps, for next
iteration gaps=: (prime, $gaps)$ ,gaps NB. repeat relative prime gaps into
new dimension of size PRIME.
NB. mark locations of values in GAPS to be processed, next iteration.
locs=: ($gaps)$ 1 (_2+ prime* 1+ i.*/}.$gaps)},($gaps)$0 NB. same shape as
GAPS, all zeroes, except 1's every PRIME positions.
NB. End function definition
)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Mon, 04 Jan 1999 00:12:58 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA-Broken!!!
Now this submission is completely unacceptable. While the author
probably intended humor, being realists (definition: the glass is dirty
and HE's going to clean it), we should be very careful about suggesting
reasons to suppress anything. The text below is actually saner, because
it is not self contradictory, than most of the bills submitted by
Feinstein, Schumer, Metzenbaum, et al.
There are real whakos in this world, and most of them have Gov't jobs!
John E. Kuslich wrote:
>
>
> Bruce Schneier wrote:
>
>> On 29 Dec 1998 01:24:02 GMT, Michael J. Fromberger
>> <[EMAIL PROTECTED]> wrote:
>> >>Well if you're so smart.... How many licks DOES it take to get to
>>
>> >>the center of a Tootsie Pop?
>> >
>> >See W. O. Owl's seminal paper on this subject, "Three Licks:
>> Getting
>> >to the Centre of the Tootsie Pop Controversy" in Journal of
>> >Idisyncratic Cryptanalysis, v.II #5, Feb. 1992, pp. 324-335.
>>
>> But he missed the meet-in the-middle attack.
>>
>> Bruce
>>
>
> The real question is whether or not a Tootsie POP is exportable.
>
> The "POP" could be considered to be an explosive device because of its
> obviously subversive name. The Tootsie Roll outer coating is a form
> of encryption since it hides the real inner "POP".
>
> All Tootsie POPS should be subject to a licensing procedure under the
> Department of Unedible Marginal Appetite Suppressant Suckers
> (DUMASS). Each Tootsie POP should be submitted to the DUMASS in
> advance of licking.
>
> Consuming a Tootsie Pop and then going to a foreign country would be
> considered export of the POP unless the consumer submits to a urine
> test prior to leaving the country to prove that the POP portion of the
> candy has not been consumed. These tests would be administered by the
> POP Inspection Sampling Service (PISS).
>
> Please understand that an actual Tootsie POP would not be exportable
> but a recipe for a POP would be exportable provided that the recipe is
> not in machine readable form such as on a computer disk or on the
> Internet. (Remember, terrorists cannot type!)
>
> Tootsie POPs smaller than 56 licks would be submitted for a one time
> review and must have the capability of being unlicked by an agency of
> the Federal Government. Any Tootsie POP not having an "Special Law
> Enforcement Unlicking Recovery Procedure" (SLURP) would be considered
> suspect.
>
> 128 Lick Tootsie POPs would be classed as Atomic Weapons because they
> somewhat resemble the atomic structure with the outer coating
> resembling the electron cloud and the inner part suggestive of a
> nucleus. A terrorist could conceivably make this connection and
> discover how to make an atomic bomb using this information. This does
> not make any sense but that would not stop it from becoming part of
> the regulation.
>
> Tootsie POPs greater than 128 licks would be prohibited for classified
> reasons. Any citizen could be told the reason but then would have to
> be summarily executed.
>
> Further regulations regarding Tootsie POPS are completely classified,
> so don't do anything. You could be arrested!!!
>
>
>
> JK
>
> --
> CRAK Software (Password Recovery Software)
> Http://www.crak.com
> [EMAIL PROTECTED]
> 602 863 9274 or 1 800 505 2725 In the USA
>
------------------------------
From: "CYFer" <[EMAIL PROTECTED]>
Subject: Visual Basic Cipher
Date: Sun, 3 Jan 1999 22:04:20 -0500
Is it possible to make a secure encryption system using VB, without using
any outside ActiveX?
------------------------------
From: r.fellner_AT_bigfoot.com (http://come.to/Delphi-Box)
Subject: ZIP encryption safe?
Date: Mon, 04 Jan 1999 07:29:55 GMT
Hello,
sorry for asking a question which might have been asked already 100s
of times before, but I'm not too familiar with crypto topics and just
asked me the following:
since I've read that especially using long ZIP passwords (15 chars and
more, including non-alphanumeric chars) takes enourmously long to
decrypt and just brute-force decryption helps.
How safe is that, compared to, let's say, 128bit Blowfish encryption ?
I just want to get a feeling, I don't need exact factors.
Thanks for your help,
Richey
------------------------------
From: r.fellner_AT_bigfoot.com (http://come.to/Delphi-Box)
Crossposted-To: soc.culture.jewish,soc.culture.israel,misc.test,news.software.nntp
Subject: Re: ZIP encryption safe?
Date: Mon, 04 Jan 1999 07:30:16 GMT
sorry, I can't read that. Anyone else?
On 3 Jan 1999 15:10:55 GMT, Mark Andreas <[EMAIL PROTECTED]> wrote:
>Attention: This is an encoded message.
>
>
>Nxej oly eag eno gzls
>dk cecf ibse erle brei
>ogwuka iigokk lgvrn hzipl wasim
>kba jfq kejtcep kslijl yhex psea
[..]
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Re: Generating random numbers (was Re: Secretz revisited)
Date: Mon, 04 Jan 1999 08:38:00 +0100
Sorry about the 80 character word wrap :-( That was for something else.
Regards,
Thomas
------------------------------
From: "~Mike Turco" <[EMAIL PROTECTED]>
Crossposted-To: soc.culture.jewish,soc.culture.israel,misc.test,news.software.nntp
Subject: Re: ZIP encryption safe?
Date: Mon, 04 Jan 1999 08:51:48 GMT
r.fellner_AT_bigfoot.com (http://come.to/Delphi-Box) wrote in message
<[EMAIL PROTECTED]>...
>sorry, I can't read that. Anyone else?
>
>On 3 Jan 1999 15:10:55 GMT, Mark Andreas <[EMAIL PROTECTED]> wrote:
>
>>Attention: This is an encoded message.
>>
>>
>>Nxej oly eag eno gzls
>>dk cecf ibse erle brei
>>ogwuka iigokk lgvrn hzipl wasim
>>kba jfq kejtcep kslijl yhex psea
>[..]
Nope. Must be pretty safe!
------------------------------
From: Brad Aisa <[EMAIL PROTECTED]>
Subject: Re: Visual Basic Cipher
Date: Mon, 04 Jan 1999 04:05:26 -0500
CYFer wrote:
>
> Is it possible to make a secure encryption system using VB, without using
> any outside ActiveX?
Certainly -- the security of a system depends on the protocol,
algorithms, and the mechanics of using it, NOT the implementation
technology.
Your best bet would be to use well known and trusted algorithms,
implemented in C and compiled into a DLL that you call from VB. This
will be faster and more trustworthy than reimplementing the algorithms
in VB. Just use VB to drive the overall protocol and interface with the
user.
--
Brad Aisa
[EMAIL PROTECTED]
"Laissez faire."
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Subject: Generating random numbers (was Re: Secretz revisited)
Date: Mon, 04 Jan 1999 07:49:17 +0100
> [EMAIL PROTECTED] wrote:
>
> > This code is just for example. It is not practical. Secretz uses a random
> > PassPhrase. I know, this totally destroys the whole point of having the
> > flexibility of an ECC passphrase, but I don't want my users entering a 5
> > letter passphrase or something like that. So I use mouse movements to
> > randomly spew 50 characters between 1 and 255 into the passphrase. The
> > passphrase entered in the New User Wizard currently serves no useful purpose.
> > In the next version user logins will be removed and that passphrase will
> > become the primary local security/encryption device.
You could generate a n byte random string (ascii 0-255), convert it to
hexadecimal and feed that to EllipticCurve1.PassPhrase. Isn't that a more
elegant solution then using 50 values between 1 and 255?!
If you want to generate a 320 bit random elliptic curve, you just use a good
PRNG to generate 320 pseudo random bits, mix it with mouse movements, date/time,
keyboard timings and a seed file (using the 320 bits as a circulair buffer and
xor the values together?). Convert it to a 640 bit hexstring and use that as a
password.
I don't know where you can find a PRNG this long, I am sure you could ask in
sci.crypt. If you only need 160 random bits you could just create a long message
with mouse positions, timings, etc and SHA-1 that. Maybe you could reverse the
message afterwards, SHA-1 the reversed message and use that to extend your
random value to 320 bits. I don't know, I hope the folks in sci.crypt do ;-)
Greetings,
Thomas
BTW Secretz is a new program that would like to become an alternative to PGP. It
is written by Clinton Begin in Dephi for Windows and there is some discussion
about it in news:alt.security.pgp. I hope you don't mind me cross posting this
question about random number generation. :-)
--
email: lastname(at)multiweb(dot)nl
PGPkey: http://x13.dejanews.com/getdoc.xp?AN=406702465
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Opinions on S/MIME
Date: Mon, 04 Jan 1999 09:17:18 GMT
In article <1999Jan3.042412.1@eisner>,
[EMAIL PROTECTED] wrote:
> In article <76n3bu$mbg$[EMAIL PROTECTED]>, "Lyal Collins"
<[EMAIL PROTECTED]> writes:
> > Please define your understanding of "normal setup"
> > At least one Australian commercial CA generates keypairs for the
> > applicant/end-user.
> > It would seem this is justified on the grounds of ensuring the key pairs are
> > random and properly created (sorry if I use the term somewhat loosely)
> >
> > Most commercial "off the shelf packages" I've seen have no accreditation of
> > the key generation process (or encryption/signing processe) - so this
> > approach has some validity from one perspective.
>
> Requiring that only certain brands of software be used to generate the
> key pairs would provide some defense against insufficent randomness
> without introducing the _large_ vulnerability of possible leaking of
> private keys for illicit purposes.
>
> Larry Kilgallen
Like the fiasco with early SSL implementations from versions of NS / MS
browsers as exploited by Wagner et al?
To quote the DDJ article:
�Until they learn their lesson and open their security programming to public
evaluation, many security experts will remain justifiably skeptical of the
company's security claims.�
Dah well,
--
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Bill Ray)
Subject: Re: PGP Keys on Smartcard
Date: Mon, 04 Jan 1999 10:02:03 GMT
>Also, I understand that RSA implementations are available on smart cards;
>the card I had most interest in was CryptoFlex but due to export regs I
>can't get one of those; I believe GemPlus over in EuroLand (im in the UK)
>has a crypto card which may do the job.
The CryptoFlex card is available in the UK without problem (I have
several hundred of them here in Guildford). Please let me know if you
want a contact with Slumberger Paris to obtain cards here as it is not
a problem.
Lots Of Love
Bill
P.S. It's a great card.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Opinions on S/MIME
Date: Mon, 04 Jan 1999 09:21:36 GMT
In article <76ibsf$lfl$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Peter Gutmann) wrote:
> "Rich Ankney" <[EMAIL PROTECTED]> writes:
>
> >This is from the PKIX (not S/MIME) RFC set. Sam is not quite correct that
> >Proof of Possession (PoP) is the same as sending your private key to the
> >CA. PoP allows the user to prove to the CA that he knows a private key
> >(e.g., sign a challenge with your private key, decrypt a challenge with
> >your
> >private key, etc.). The ability to archive your private key IS an OPTIONAL
> >part
> >of both PKIX certificate management protocols (CMP and CMC) but is not
> >the same as PoP.
>
> Since several governments (principally the US) have been trying to implement
> some form of GAK for years, and failing miserably (initially with Clipper,
> more recently with the Committee to Develop a Federal Information Processing
> Standard for the Federal Key Management Infrastructure farce where members
> were asked to resign at the final meeting so a quorum could be achieved). If
> the IETF is going to build a GAK-ready system for them, how long do you think
> it'll take before its use becomes mandated by law? The UK is trying to do
> this right now, and their GAK uses the PKIX protocols to get at users keys.
> It doesn't matter what the IETF says about the matter, if you build it...
>
> Peter.
>
>
I'm with you Peter...
It is believed that the inclusion of PoP was added to the S/Mime standard at
the request of the USG. Personally I believe that there should be a clear
statement on whether the S/Mime standard requires unconditionally or
functionally trusted TTPs � not some fuzzy standard that is subject to
political pressure.
Because we all know what way that'll swing, don't we?
--
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Help (How long can a post be seen?)
Date: Mon, 04 Jan 1999 10:32:55 -0100
rosi wrote:
>
> Hi,
>
> This is not related to any cryptographic topic.
>
> I would like to know how often and when old posts are purged. It
> seems to be used to staying longer than now (I can be very wrong).
>
It's different for everybody, it depends on your individual ISP.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
** 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
******************************
