Cryptography-Digest Digest #894, Volume #12 Wed, 11 Oct 00 06:13:01 EDT
Contents:
Re: working with huge numbers (Ray Dillinger)
re: working with huge numbers ("DeSilva")
Re: A new paper claiming P=NP (Bill Unruh)
Re: MITM attack ([EMAIL PROTECTED])
Re: No Comment from Bruce Schneier? (Greggy)
Re: Rijndael implementations ("Brian Gladman")
[Q] CertGetNameString' : undeclared identifier CryptoAPI ("Soyeoun Park")
Re: pass phrases and key generation (and Kerberos) (Paul Rubin)
Re: NIST RNG Tests ([EMAIL PROTECTED])
Re: Dense feedback polynomials for LFSR ([EMAIL PROTECTED])
Re: How Colossus helped crack Hitler's codes (Frode Weierud)
Re: Why trust root CAs ? (Vernon Schryver)
Re: CRC vs. HASH functions (Tim Tyler)
Re: Microsoft CAPI's PRNG seeding mechanism (Tim Tyler)
----------------------------------------------------------------------------
From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Re: working with huge numbers
Date: Wed, 11 Oct 2000 06:21:16 GMT
Eric Young <[EMAIL PROTECTED]> wrote:
: Well, in my case I originally wrote my bignum library specifically to learn
: how to do large number division. I was intimidated by it, so I took it as
: a challenge to learn how it was done :-).
When I'm learning a new language, one of the first things I always
write is a bignum library. I don't go for ultimate efficiency
with it though; I just toss it together and make sure it works
correctly.
Using such libraries for crypto has not really been a problem
at all; Okay, my modular exponentiation routine may take three
or four eyeblinks instead of one -- but I don't really care
because encryption/decryption tends to be quite fast, measured
in human terms, anyway. So I don't deal with the machine code
and hand-tweak processor scheduling and carefully arrange blocks
to fit into the cache on particular CPUs (all of which techniques
I see in the PGP code), I just write numerical algorithms on 16-
bit and 32-bit integers. They are efficient *algorithms*,
so they run in the "right" order of magnitude -- but chasing down
every last bit of performance available is just not worth my time
or the trouble of verifying the resulting assembly-language code.
If the task were cryptanalysis, or brute-force trying of keys,
then sure, it would be time to work over the bignum library
with a fine-toothed comb and bum it into a state of high
perfection. But generally, cryptography (which is a much simpler
task than cryptanalysis) is fine with simple straightforward,
general implementations. And it makes the code ten times easier
to verify as correct.
Bear
------------------------------
From: "DeSilva" <[EMAIL PROTECTED]>
Subject: re: working with huge numbers
Date: Wed, 11 Oct 2000 08:32:08 +0200
So can anyone direct me to an online source of info on how to do this?
Quite frankly right now i dont want to sit and close read sourcecode in
order to figure out how and why one specific implementation does this, i
would much rather read some sort of tutorial on the subject... and right now
i am not really interested in buying books on the subject.
Ray Dillinger <[EMAIL PROTECTED]> skrev i en
nyhedsmeddelelse:wFTE5.3255$[EMAIL PROTECTED]
> Eric Young <[EMAIL PROTECTED]> wrote:
>
> : Well, in my case I originally wrote my bignum library specifically to
learn
> : how to do large number division. I was intimidated by it, so I took it
as
> : a challenge to learn how it was done :-).
>
> When I'm learning a new language, one of the first things I always
> write is a bignum library. I don't go for ultimate efficiency
> with it though; I just toss it together and make sure it works
> correctly.
>
> Using such libraries for crypto has not really been a problem
> at all; Okay, my modular exponentiation routine may take three
> or four eyeblinks instead of one -- but I don't really care
> because encryption/decryption tends to be quite fast, measured
> in human terms, anyway. So I don't deal with the machine code
> and hand-tweak processor scheduling and carefully arrange blocks
> to fit into the cache on particular CPUs (all of which techniques
> I see in the PGP code), I just write numerical algorithms on 16-
> bit and 32-bit integers. They are efficient *algorithms*,
> so they run in the "right" order of magnitude -- but chasing down
> every last bit of performance available is just not worth my time
> or the trouble of verifying the resulting assembly-language code.
>
> If the task were cryptanalysis, or brute-force trying of keys,
> then sure, it would be time to work over the bignum library
> with a fine-toothed comb and bum it into a state of high
> perfection. But generally, cryptography (which is a much simpler
> task than cryptanalysis) is fine with simple straightforward,
> general implementations. And it makes the code ten times easier
> to verify as correct.
>
> Bear
>
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
Date: 11 Oct 2000 07:14:16 GMT
In <[EMAIL PROTECTED]> glenn <[EMAIL PROTECTED]> writes:
>Irrelevant question, but is there any way of converting a pdf file to
>ps?
pdf2ps
Both are Unix programs available with many Linux distributions. They
were apparently written by Adobe or adobe people, so may well be
available on other platforms. Alternatively, Acroread will produce a ps
file from a pdf file ( just "print to file" as a postscript printer).
xpdf will also do it.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: MITM attack
Date: Wed, 11 Oct 2000 07:44:18 GMT
Thank you. I know of the Man in the middle attack, i just didn't
associate it to its shortened version !
In article <[EMAIL PROTECTED]>,
Dido Sevilla <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Excuse me for the ignorance but could you explain what MITM is?
> >
>
> MITM = Man In The Middle. It's a network attack in a client-server
> system where the attacker pretends to be the server to the client, and
> pretends to be the client to the server. Subtle modifications in
> network traffic done this way can have disastrous results...
>
> --
> Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
> ICSM-F Development Team, UP Diliman +63 (917) 4458925
> OpenPGP Key ID: 0x0E8CE481
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: No Comment from Bruce Schneier?
Date: Wed, 11 Oct 2000 07:42:51 GMT
Honestly, I was hoping Twofish would win. I thought it was Bruce's
turn for the gold.
> I expected to hear from a few people, Brian Gladman, the author's of
> Rijndael themselves etc... But most of all, I expected Bruce to say
> something on sci.crypt. Something sportsman-like, like, "Rijndael is
a
> good algorithm, designed by two people who know what they are doing.
I
> want to congratulate them on being selected as the AES winner."
>
> Comments? From Bruce?
> Albert
>
--
If I were a cop, I would refuse to go on any no knock raid.
But then, I am not a cop for basically the same reasons.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Rijndael implementations
Date: Wed, 11 Oct 2000 09:03:50 +0100
"Paul Pires" <[EMAIL PROTECTED]> wrote in message
news:LxNE5.527$[EMAIL PROTECTED]...
> <snip>
> >
http://www.btinternet.com/~brian.gladman/cryptography_technology/rijndael/in
> > dex.html
> >
> > where I have just updated my own implementation (in C++). On the
200MHz
> > Intel reference platform it offers around 70Mbits/second using large
tables
> > but other options are provided as well.
>
> Hope you don't mind a dumb question. If a Megabyte is 1024^2 bits
(1.048576
> million
> bytes) as opposed to1 million bytes, is a Mbit 1 million bits or something
else?
>
> Paul
In my code 1Mbit/second = 10^6 bits/second - that is, the M is being used in
its scientific meaning as a prefix for 10^6.
I simply measure the number of cycles to encrypt a 128 bit block and then
calculate how many bits per second this represents and then divide by 10^6.
The speed would be reported 5% lower if the 2^20 convention was being used.
Brian Gladman
------------------------------
From: "Soyeoun Park" <[EMAIL PROTECTED]>
Subject: [Q] CertGetNameString' : undeclared identifier CryptoAPI
Date: Wed, 11 Oct 2000 17:18:13 +0900
Hi!! There.. It's nice to meet all of you on the internet.
I'm new to use CryptoAPI, at the moment having a lot of problems..
I've compiled some examples downloaded from MSDN but it kept giving me the
following
errors!!
C2065: 'CertGetNameString' : undeclared identifier
C2065: 'CERT_NAME_SIMPLE_DISPLAY_TYPE' : undeclared identifier
C2065: 'CERT_SIGNATURE_HASH_PROP_ID' : undeclared identifier
error C2065: 'CERT_DESCRIPTION_PROP_ID' : undeclared identifier
error C2051: case expression not constant
error C2065: 'CERT_ACCESS_STATE_PROP_ID' : undeclared identifier
error C2051: case expression not constant
C2065: 'CERT_SMART_CARD_DATA_PROP_ID' : undeclared identifier
error C2051: case expression not constant
error C2065: 'CERT_EFS_PROP_ID' : undeclared identifier
I've been trying to find CertGetNameString class in <wincrypt.h> but I don't
think I could.
I did install Platform SDK, do I need to set up the latest version?
Please please help me out !! Any help will be really appreciated.
Have a nice day!!
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: pass phrases and key generation (and Kerberos)
Date: 11 Oct 2000 01:24:46 -0700
Ken Raeburn <[EMAIL PROTECTED]> writes:
> What schemes are preferred for (deterministically) generating keys
> from pass phrases?...
>
> Does a CBC-MAC, using a key and initial vector either predefined and
> public or derived from the input string, do good mixing and entropy
> preservation?
CBC-MAC with a fixed IV has the disadvantage that with a one-block
passphrase (anything <= 16 bytes because AES has 128-bit blocks), the
passphrase can be decrypted.
I'd try something like:
1) Compute 128-bit AES CBC MAC of passphrase, with a fixed key and IV,
preferably secret. Call the result K1.
2) Initialize K1 as a 128-bit AES key and use it to encrypt itself,
i.e. find E(K1, K1).
3) Use the ciphertext from 2) as the final key.
> Should I give up on encryption-based schemes and just go with SHA1 (or
> SHA2 eventually)?
I don't think it matters much. Passphrases aren't a good way
represent keys in the first place. They should only be used for low
security applications. Nobody will break even a reasonably good
password-to-key crunching scheme, if they can instead guess the
passphrase by brute force, or sneak software onto the user's computer
to capture the keystrokes and get the passphrase that way, etc.
>[moved from top of message]:
> I'm looking at putting together a spec for using Rijndael and/or
> Twofish in Kerberos. ...
It gets slightly off-topic, but can you say if there's any point in
using Kerberos these days, other than to interoperate with existing
Kerberized networks? It was a neat piece of software but needed a lot
of complexity and careful design to do its work using only secret-key
algorithms. Now that the important public-key patents have expired,
isn't it simpler to use SSH, SSL, IPSEC, and so forth?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST RNG Tests
Date: Wed, 11 Oct 2000 08:15:44 GMT
Well, i managed to get the test data supplied by NIST. So far i've only
tried the data.pi file and i am running into problems with the
overlapping and non-overlapping tempplates tests. I don't the same
results as those specified in the user manual.
Also, i have emailed NIST asking about porting the code to a PC and the
answer i got was:
>I do not have a list of specific changes that are necessary for porting
>to a PC. If you have a PC with Linux, the code seems to work fine as
>is.
Regards,
Brice.
In article <CFHE5.1969$[EMAIL PROTECTED]>,
"Paul Pires" <[EMAIL PROTECTED]> wrote:
>
> <[EMAIL PROTECTED]> wrote in message
news:8runi9$maq$[EMAIL PROTECTED]...
> > I have actually compiled the code on a Sun computer running the
Solaris
> > OS. I was hoping maybe that version would work properly. I have run
it
> > on some data but i can't check it against anything.
> >
> > The test data mentioned in the user documentation provided by NIST
> > doesn't seem to be present when i unpack the compressed files
(sts.tar &
> > sts.data.tar).
> >
> > I will email the implementors to see if they can provide me with
test
> > data.
> >
> > Brice.
> >
> > In article <[EMAIL PROTECTED]>,
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > [EMAIL PROTECTED] wrote:
> > >
> > > > I have finally managed to compile the new NIST Random Number
> > Generator
> > > > tests. However, i don't have any data to make sure the code does
> > what
> > > > it's supposed to do. Could anyone supply me with some data they
have
> > > > used and then i could compare my results with theirs?
> > >
> > > As discussed recently, the package could have some problems
> > > on PC. Please contact the implementors at NIST and let us
> > > know that the suite runs correctly on PC and about the
> > > checks you mentioned.
>
> A buddy helped me out and I have a copy copiled to run under Windows
> I have not had time to work with it yet (work intrudes). NIST could
have
> specified a simple, concise confidence check since they opted not to
> release compiled and verified code. I hope to be back at it later this
> week and will advise on what I find.
>
> Paul
>
> > >
> > > M. K. Shen
> > >
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Dense feedback polynomials for LFSR
Date: Wed, 11 Oct 2000 08:28:01 GMT
> Incredible explanation! I actually understood
it!
> I was just reading Bruce S's book "Applied
> Cryptography" and wondering to myself why he
> recommends using dense polynomials, but only
> gives examples of sparse polynomials. Perhaps
> he's working for the NSA ?
>
> On another note, it seems to me that making the
> polynomial itself a part of the key would
> greatly increase security, but that possibility
> is barely mentioned in his book.
> Do you have any info on that?
One possibility is to create and store a set of
polynomials and choose one depending on the key
every time the key changes, e.g. by using a
hash function.
Andi
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Frode Weierud)
Subject: Re: How Colossus helped crack Hitler's codes
Date: 11 Oct 2000 09:08:52 GMT
Reply-To: [EMAIL PROTECTED]
John <[EMAIL PROTECTED]> writes:
>You can find a lot of information about BP on their web site;
>http://www.bletchleypark.org.uk/
If you are interested in the technical details have rather a
look at Tony Sale's own Web pages at:
http://www.codesandciphers.org.uk/index.htm
Here you will find information about Enigma, Lorenz SZ42 and the
Colossus as well as several of Tony's lectures.
Well worth visiting.
Frode
--
Frode Weierud Phone : +41 22 7674794
CERN, SL, CH-1211 Geneva 23, Fax : +41 22 7679185
Switzerland E-mail : [EMAIL PROTECTED]
WWW : home.cern.ch/frode/
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: Why trust root CAs ?
Date: 10 Oct 2000 13:08:03 -0600
In article <8rvdak$7ja$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>I could associate with your claim on "snake oil" if all Versign was
>doing was providing an encryption/authentication service that is
>essentially already embedded with SSL; Or, Versign simply provided
>services equivalent to a IP/DNS WHOIS lookup. However, Verisign
>provides a service that goes well beyond what anyone currently does with
>the existing tools. True, Verisign uses those same tools in providing
>services. Just don't get the tools confused with the services that uses
>the tools. Before Verisign issues a business certificate, Verisign
>checks up on the legitamacy of the business, including checking up on
>articles of incorporation, DUNS numbers, and assorted other information
>that establishes the existence of a business.
I wonder if you've ever looked into buying a Verisign or Thawte
certificate. I started through the process with Thawte to sign a product
distributed via the web before realizing I was wasting time and money.
They required merely superficial evidence that I control the domain name
rhyolite.com and copies of some business papers. I don't see why anyone
would worry about being defrauded by a crook that could not immediately
see how to get around what Thawte required. My recollections of Verisign's
requirements (and a quick check a few minutes ago) is that they are similar.
In other words, since when is a DUNS number a proof of identity, honesty,
financial stability, or anything else?
In still other words, your main protection is that it would be hard to
pretend to be Amazon.com simply because Amazon.com is what it is in the
real and network worlds. Where you really need PKI is dealing with such
as Rhyolite Software, but it would be easy to convince Verisign and so
anyone who believes in Verisign's PKI that you are the proprietor of
Rhyolite Software.
> In essence, the
>certificate tell me, the consumer, that a site meets the minimum
>standards identified in Verisign's Certification Practices Statement.
>In the world of digital signatures and Public/Private keys, it's easy to
>lose focus on what service Verisign is really providing here.
See http://www.verisign.com/gov/ieca/index.html
http://www.verisign.com/server/enroll/globalpreparing.html
and especially http://www.verisign.com/repository/cps/dod/ieca.html
and then please tell me what they tell you the consumer.
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: CRC vs. HASH functions
Reply-To: [EMAIL PROTECTED]
Date: Wed, 11 Oct 2000 09:11:48 GMT
Mack <[EMAIL PROTECTED]> wrote:
: Having been working hard and not here for a while
: the topic of CRC vs. HASH functions came up in a thread.
: 1) CRC are faster than HASH functions of
: comparable size. That is a fact. Many
: hash functions use a CRC like layer at the
: top to mix in data linearly. SHA-1 is no exception.
While hash functions take longer to evaluate in software, they often have
a layered structure that allows hardware implementations to accept new
inputs before the last inputs have been completely processed, allowing
concurrent processing to take place.
Consequently - while the area used is much increased when compared to a
CRC - there's not anything like so much difference in throughput speed as
a software engineer might expect.
One field where this seems relevant is when condensing entropy from random
sources.
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
Crossposted-To: sci.crypt.random-numbers
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Microsoft CAPI's PRNG seeding mechanism
Reply-To: [EMAIL PROTECTED]
Date: Wed, 11 Oct 2000 09:24:27 GMT
Volker Hetzer <[EMAIL PROTECTED]> wrote:
:> : Jack Love dropped into the real world with a crash and proclaimed...
:> :>Windows 2k was recently given a C2 rating.
: Any source for this?
M$'s main C2 page suggests that this is false (by failing to mention it):
http://www.microsoft.com/technet/security/c2eval.asp
According to a source cited earlier this year on:
http://www.gcn.com/vol19_no3/news/1284-1.html
``Agencies that have a �hard requirement� for C2 security will have to
wait two or more years before adopting Microsoft Windows 2000 [...]''
--
__________ http://alife.co.uk/ http://mandala.co.uk/
|im |yler [EMAIL PROTECTED] http://hex.org.uk/ http://atoms.org.uk/
------------------------------
** 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
******************************
