Cryptography-Digest Digest #3, Volume #11 Sat, 29 Jan 00 20:13:00 EST
Contents:
Re: *** ECC Strong and Weak combined (Greg)
Re: Mac encryption algorithm? (Paul Schlyter)
Wireless PKI now or later (Drew Cutter)
Re: *** ECC Strong and Weak combined (Greg)
Re: NIST, AES at RSA conference (CLSV)
Re: Anyone read this book? (wtshaw)
A question about odd grilles (wtshaw)
Re: NIST, AES at RSA conference (CLSV)
Re: IDEA (Boris Kazak)
Re: A question about odd grilles (Boris Kazak)
Re: Math contest winner from Ireland... (James Muir)
Re: A question about odd grilles (Mok-Kong Shen)
Re: "Trusted" CA - Oxymoron? (Timothy M. Metzinger)
Re: Help needed on peculiar use of cryptography (David A Molnar)
Re: How much random needed for random ("Jan P. Monsch")
----------------------------------------------------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Sat, 29 Jan 2000 21:08:15 GMT
> This depends strongly on the protocol you are using. If a
> client ever sends or receives message that is not doubly
> encrypted by the servers key, then you have reduced the
> amount of work needed for a brute force attack by 2^(0.80*KeyLen).
I don't follow this at all. How does twice encrypting traffic
improve security if the original secret keys are transmitted
with what you think is a weak key?
> If you are using a 256 bit ECC key, the brute force
> work is 2^51. Such a small key can be brute forced
> with today's hardware
Okay, I tend to agree, that 51 bits is questionable. But say
I am using a 163 bit field and I use a key space limited to
64 bits? Would you agree that it would remain secure for at
least a year or two?
>
> [EMAIL PROTECTED]
>
> "Greg" <[EMAIL PROTECTED]> wrote in message
> news:86o2jl$6ba$[EMAIL PROTECTED]...
> > I was doing some testing recently with my ECC code and I noticed
> > that if I have a curve over a large field and a key that has the
> > most significant bit set, it takes about one second to complete
> > a point operation.
> >
> > Yet, if I keep the key value very small where, say, the 80% MSBs
> > are clear, then the operation is very fast. This makes me think
> > that given a very strong public key for a server, a client can
> > use a random small private key which can be used to quickly generate
> > both the client's public key and shared secret. The client side
> > is very fast on these operations because its private key is
> > small. The client's public point is then sent to the server
> > and the server performs a point operation of its own to derive
> > the same shared secret.
> >
> > While the server takes as long as usual, the benefits of this
> > strategy (limiting the client private key size) include:
> >
> > Faster client key setup
> > Faster client secret setup
> > Weak secret does not weaken server public key
> >
> > Any thoughts?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Mac encryption algorithm?
Date: 29 Jan 2000 21:30:10 +0100
In article <86v94o$9br$[EMAIL PROTECTED]>,
Vernon Schryver <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
>>Paul Schlyter wrote:
>>> And why is this [little-endian] byte order "wrong" ?
>>
>>It's pretty evident to people who've dealt extensively with both,
>>that little-endian is "more natural" from the point of view of
>>arithmetic and addressing. For example, consider how it supported
>>pass-by-reference integers in DEC PDP-11 FORTRAN; that was so
>>important that the implementation of 32-bit integers did not
>>match the mixed-endian storage layout of the FP-11 floating-point
>>unit (which included support for 32-bit integers), despite the
>>speed advantage had the FP-11 layout been used. With big-endian
>>representation, the low-level operations constantly have to take
>>word size into account; little-endian representation is much more
>>cleanly extensible.
>
> That is a religious view without factual basis. Regardless of byte order,
> your compiler and everything else must continually take the width of
> numbers into account.
Not always, on little-endian machines...
> It makes no real difference whether you increase an index to get to
> the more significant bits of a number, or decrease the index.
Well, the point here is that on little-endian machines you don't need
to decrease the index.
Suppose you have a function which needs one byte as an argument, and
it receives a pointer to that argument. Also suppose that when
calling that function, you could pass a byte, a short integer, or a
long integer. Now what will happen?
On a big-endian machine, the function must somehow be made aware of
the type of the argument, and must then increase the byte index as
needed. Alternatively, the code for calling this function must first
convert the argument to a byte, before passing a pointer to it to the
function, if the original argument is wider than one byte.
On a little-endian machine, the function merely grabs the byte
pointed to by the pointer. And the code calling that function need
not do any type conversion, since the low-order byte will be first,
no matter if the argument is a short or a long integer. The result
will be somewhat smaller code size and somewhat faster execution.
> That and whether the "starting" address of the number is the most
> or least significant digit (i.e. word or byte) is the sum total of the
> difference.
>
> And yes, I've written code for big and little ending systems, including
> some low level numeric stuff such as transcendental and multi-precision
> libraries.
>
> Consider that more than one non-Intel CPU can be used in either big or
> little endian systems. Some systems have all of the hardware required to
> run both big and little endian programs at the same time, thanks to a
> process status bit. You don't find biendian operating systems because of
> the unendurable hassles inside the operating system of dealing with system
> calls from both flavors, and because application writers don't like having
> to use ASCII, BCD, or even XDR for all disk and inter-process data.
>
> (doesn't even Intel's Mercede have the per-process endian bit like MIPS?
> or is it merely a CPU configuration bit?)
>
> I used to work at a major UNIX vendor were pointy-haired bosses decided
> that a biendian UNIX compliant with the BSD, POSIX and SVR4 (de facto)
> standards was the ticket. It was more than a year before that particular
> nonsense fell off the schedules, and people with brains could stop hurting
> themselves by dealing with biendian kernel hassles. Of course, the biggest
> pointy-haired advocate later claimed to have opposed it all along.
Well, here you do have a point: one should definitely stick to
little-endian OR big-endian, and never try to do both in the same
system, or else there may easily be chaos and madness. On the other
hand, no-one here did advocate bi-endian systems.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
Date: Sun, 30 Jan 2000 16:30:11 -0500
From: Drew Cutter <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Wireless PKI now or later
I was wondering what this group thinks of Wireless PKI offer by
Baltimore , Entrust , certicom ? Is wireless PKI something I could use
today with assurance or should I wait ? Which encryption is better of
the three I mention ?
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: *** ECC Strong and Weak combined
Date: Sat, 29 Jan 2000 21:38:27 GMT
> > This makes me think that given a very strong public key for a
> > server, a client can use a random small private key which can
> > be used to quickly generate both the client's public key and
> > shared secret.
>
> This can be broken in O(2^(n/2)) work, where n is the number of
> bits that can vary in the private exponent (e.g. using the
> Pollard lambda algorithm).
I thought that n was related to the field size, not the number of
bits in the private exponent that can vary.
Also, my example of 80% was extreme. Let's say a field of 163 bits
and a key space of 64 bits or 80 bits. Even if n were related
to the size of the key, would you say 80 bits was secure for at
least a couple of years?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 22:10:37 +0000
"A [Temporary] Dog" wrote:
> On Sat, 29 Jan 2000 18:58:21 +0000, CLSV <[EMAIL PROTECTED]> wrote:
> >If breaking a cipher is equivalent to solving (a hard
> >instance of) a problem in NP and someone would prove
> >that P != NP then the cipher can not be broken with
> >polynomial effort.
> A big if. Perhaps I'm missing everthing, but I thought the whole
> point of the thread was that we had no way of knowing that, in your
> words "breaking a cipher is equivalent to solving (a hard instance of)
> a problem in NP."
Well this thread has a certain philosophical vaguenes
so there is no point in taking things to the limit but
there are ciphers based on problems like the RSA-problem
that are conjectured to be equivalent to hard problems.
It is not unreasonable to think that in the future
ciphers will be developped the breaking of which is
proveable equivalent to solving a hard problem.
Regards,
CLSV
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Anyone read this book?
Date: Sat, 29 Jan 2000 15:19:36 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paris Guffey) wrote:
> Hello,
>
> I saw this book at Borders and only had time to briefly flip through
> it. Has anyone read it, or could anyone recommend it to me? I know
> it covers different crypto systems, but does it do a good job about
> cryptanalysis? It looks like it would be a handy reference to have.
>
> Codes, Ciphers and Other Cryptic and Clandestine Communication: 400
> Ways to Send Secret Messages from Hieroglyphs to the Internet
> by Fred B. Wrixon
>
> Any comment would be greatly appreciated. Post or email.
>
> --
> Paris Guffey
It is a good book, with a few typos. Enjoy.
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: A question about odd grilles
Date: Sat, 29 Jan 2000 15:35:33 -0600
Considering that a grill with an odd number of characters has a character
directly in a matrix, is there a traditional way to handle it. If the
hole were cut, that character would appear 4 times, once each with each
setting.
The solution might be that the middle characters is ignored, simply a
null, or that it was worked into the passage.
I see that it would be useful simply to handle it separately, putting it
in ciohertext or plaintext eactly in the middle, allowing a prefect square
of characters, but no hole.
Any ideas?
--
About injustice, the stronger I get the meaner I feel, or is it the
other way around. Do not respect sacred cows that seek to trample you while preaching
about the good they do.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sat, 29 Jan 2000 22:22:08 +0000
Joseph Ashwood wrote:
>
> > If breaking a cipher is equivalent to solving (a hard
> > instance of) a problem in NP and someone would prove
> > that P != NP then the cipher can not be broken with
> > polynomial effort.
> As I learned not so long ago, the reality is that does not
> quite work. The P != NP proof will likely be single problem
> oriented.
Can you explain what you mean with "single problem oriented"?
> This is a very important distinction, the proof of
> P != NP will mean quite a bit for security, but it will not
> be proof against knownplaintext attacks, more work is needed
> to protect against that.
Suppose I have a stream cipher of which a prove exists
that calculating the next output bit can not be done
with polynomial effort (given all previous output bits
and an unknown key). Wouldn't this be safe against a
known plaintext attack?
Regards,
CLSV
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: IDEA
Date: Sat, 29 Jan 2000 15:06:43 -0800
Reply-To: [EMAIL PROTECTED]
Try <http://www.rpini.com> and browse their Crypto CD online.
The site is in Switzerland.
Best wishes BNK
=======================================
Arie Gerszt wrote:
>
> Hi
>
> I am a student from Switzerland. I was
> searching for a good resource concerning
> the IDEA encryptio algorithm. I was looking
> for a C/C++ source for compiling under Linux.
> Does anybody have some good links, hints or
> other resources concering IDEA and linux?
>
> Thanks for your help,
>
> regards arie
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: A question about odd grilles
Date: Sat, 29 Jan 2000 15:18:27 -0800
Reply-To: [EMAIL PROTECTED]
One workable solution can be to use this central hole right during the
first quadrant positioning, and ignore it during the 3 remaining
quadrants. This is easy to do while encrypting and while decrypting.
Best wishes BNK
==============================================
wtshaw wrote:
>
> Considering that a grill with an odd number of characters has a character
> directly in a matrix, is there a traditional way to handle it. If the
> hole were cut, that character would appear 4 times, once each with each
> setting.
>
> The solution might be that the middle characters is ignored, simply a
> null, or that it was worked into the passage.
>
> I see that it would be useful simply to handle it separately, putting it
> in ciohertext or plaintext eactly in the middle, allowing a prefect square
> of characters, but no hole.
>
> Any ideas?
> --
> About injustice, the stronger I get the meaner I feel, or is it the
> other way around. Do not respect sacred cows that seek to trample you while
>preaching about the good they do.
------------------------------
From: James Muir <[EMAIL PROTECTED]>
Subject: Re: Math contest winner from Ireland...
Date: Sat, 29 Jan 2000 23:26:45 GMT
Sarah Flannery's Public-Key Algorithm
http://www.counterpane.com/crypto-gram-9912.html
-James
In article <[EMAIL PROTECTED]>,
ef <[EMAIL PROTECTED]> wrote:
> Hello-
> A year or two ago there was a high school girl from Ireland that won a
> math contest for her solution dealing with algorithms that would
produce
> faster methods of encryption.
> Does anyone know her name or what's happened to her since? Very bright
> person.
> Thankyou,
> Eric
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A question about odd grilles
Date: Sun, 30 Jan 2000 00:51:24 +0100
wtshaw wrote:
>
> Considering that a grille with an odd number of characters has a character [snip]
I have never actually used a grille, hence a question:
Isn't it that for a turning grille the holes cut can't be entirely
arbitrary, for otherwise some of the holes at the four positions
could possibly overlap? What are the general rules for cutting
the holes?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Timothy M. Metzinger)
Subject: Re: "Trusted" CA - Oxymoron?
Date: 29 Jan 2000 23:48:29 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (John
G. Otto) writes:
>The problem is that the whole scheme is half-baked.
>
>You do NOT need to know who the person is; you just need to be
>sure the funds are transferred, or vice versa, that the quid
>pro quo of the deal will exist.
>
>Digicash's scheme provides both anonymity and assurance of
>the transfer. The only draw-backs WRT privacy are that they
>have a way to report the transactions and is subject to a
>traffic monitoring.
as many people have indicated, for a transfer of wealth, the identities of the
individuals aren't important, only the identities of the two containers ("from"
and "to") matter.
But for signed documents, legal briefs, title transfers, and other
applications, it IS important to verify individual identities.
While many commercial CA's don't verify identity, some do... Digital Signature
Trust Corp, Verisign, Baltimore (formerly GTE CyberTrust), and the DOD CA's do
have certificate policies where they do a face-to-face registration of
individuals, and stand behind the certificate's binding.
Timothy Metzinger
Commercial Pilot - ASEL - IA AOPA Project Pilot Mentor
DOD # 1854 '82 Virago 750 - "Siobhan"
Cessnas, Tampicos, Tobagos, and Trinidads at FDK
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Help needed on peculiar use of cryptography
Date: 29 Jan 2000 23:47:45 GMT
David P Jablon <[EMAIL PROTECTED]> wrote:
> Salting the hash as suggested in another post merely obfuscates
> the result, unless the salt is kept more securely than the hash data.
>From what I can tell, this may be reasonable in the situation. The company
is turning over the hash data to the lawyer/economist in the form of
"encrypted" employee IDs. There is no reason why the hash needs to
be kept around, _if_ we trust the company to perform the
transformation correctly. The salt could even be destroyed after the data
is produced.
The flaw, as David Scott has pointed out, is that now we cannot guarantee
collision freeness.
One suggestion in another post was to try several different salts until
colllision freeness occurs. I'm not sure how many you would need, though.
Perhaps another way is to try different salts and run the hash on the data
until we have a collision-free mapping for the particular set of
employee ID numbers at issue.
My assumption is that the company can look at the hashed IDs and check
for collisions *before* turning them over to the lawyer. So if a collision
occurs, change the salt or salts and try again. This assumes that
we need only avoid collisions within the same company. It also assumes
that a collision-free map for the particular set of data will not be
so rare that finding one will take "too long."
I also assume that the hash function does not preserve correlations
present in the original data , like adjacent values or one ID being
a multiple of another, and so on. This may not be a good assumption; does
anyone know of results one way or the other, besides the fact
that we can always feed the hash a "description of itself" (due to
Canetti, Goldreich, and Halevi).
Thanks,
-David
------------------------------
From: "Jan P. Monsch" <[EMAIL PROTECTED]>
Subject: Re: How much random needed for random
Date: Sun, 30 Jan 2000 00:13:51 +0000
Have you checked if you have the JIT enabled in your VM? I have discovered
that running encryption routines with a JIT makes them execute much
faster. In
my case it performed about 5 times faster.
Regards Jan
Scott Nelson wrote:
> On Sun, 23 Jan 2000 11:59:15 +0200, "Yoni M." <[EMAIL PROTECTED]> wrote:
>
> >I'm using SecureRandom (java) in my SSL implementation to produce the
> >random bytes needed for the challanges. My problem is performance, it
> >takes too long to generate the bytes. If I'm using a simple Random
> >everything is much faster.
>
> If your problem is performance, then you should consider
> a language built for performance, rather than compatibility.
> Java is nice for some things, but this isn't one of them.
>
> >Can I initialize the secure random with the current time (long), or
> >isn't it enough ?
> No, it's not enough. If you want to build a secure rng,
> then read the Yarrow page http://www.counterpane.com/yarrow.html
> It discusses this, and many other pitfalls.
>
> >This way is much faster than initializing the
> >SecureRandom without any seed.
> Faster yes, but not secure.
>
> >Does anyone knows of a short cut or suggestion how to improve the
> >performance without reducing security ?
> >
> Not in Java.
> Normally, you can speed initialization by keeping a pool
> of entropy handy which is then hashed for use. That implies
> the ability to write files, which is counter to the Java
> philosophy. (and introduces another whole host of problems.)
> For your app, this would probably need to be a separate program.
>
> Scott Nelson <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
