Cryptography-Digest Digest #498, Volume #13 Fri, 19 Jan 01 13:13:00 EST
Contents:
Re: Kooks (was: NSA and Linux Security) (digiboy | marcus)
Re: Comparison of ECDLP vs. DLP (Splaat23)
Re: ___ECC encrypt/decrypt (DJohn37050)
Re: block algorithm on variable length without padding? (John Myre)
Re: ___ECC encrypt/decrypt (Bob Silverman)
Re: Comparison of ECDLP vs. DLP (Roger Schlafly)
Faculty Opening - Applied Cryptography, Network Security Protocols (Adam Victor Reed)
Re: Any good source of cryptanalysis source code (C/C++)?
(=?Windows-1252?Q?Lu=EDs_Casanova?=)
Crypting byte by byte ("dexMilano")
Re: Kooks (was: NSA and Linux Security) (Greggy)
Re: Why Microsoft's Product Activation Stinks (Gordon Walker)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Re: Comparison of ECDLP vs. DLP (DJohn37050)
----------------------------------------------------------------------------
From: digiboy | marcus <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 15:25:43 GMT
In article <948fut$j3p$[EMAIL PROTECTED]>,
Greggy <[EMAIL PROTECTED]> wrote:
> So we can see who the real kook is.
I think it's clear to everyone...
--
[ marcus ] [ http://www.cybergoth.cjb.net ]
[ ---- http://www.ninjakitten.net/digiboy ]
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Fri, 19 Jan 2001 15:28:14 GMT
Just because it passes statistical tests doesn't mean it's
cryptographically secure. No amount of statistical testing can prove
that a RNG is unpredictable and thus secure. For example, most every
good CSPRNG passes statistical tests, but if I know the key it is 100%
predictable until the key changes. Even the C library rand() probably
passes a bunch of tests, but it is worse than worthless.
In general, this dialog has been fairly ridiculous. In any scheme,
there has to be some trust in the implementor of the scheme. Both RSA
and DLP can both be verified by the key generator after keygen is
complete to check for errors, and even if some weird error occurred
during keygen the checker will pick it up because the likelihood of the
checker having an error that will EXACTLY counter the other error is
small.
In the case of RSA, _that is it_. A faulty RSA key has no bad aspects
aside from not working, and it is in the keyholder's best interest to
make sure his key is valid and secure against attacks. In the case of
DLP, there are situations where someone else, to preserve his own best
interests, must remotely verify the validity of someone else's key.
This is just an aspect of DLP, has been solved in both interactive and
non-interactive proofs, and is one of the many differences between RSA
and DLP that keep both of them as viable methods. Personally, EC-DLP
and RSA are really almost tied, and the circumstances will totally
guide me in my choice. This is not the place to mention the
comparisons, but just search the web if you want a side-by-side
comparison.
However, if speed of implementation is a factor, I _do_ choose RSA
because in any language with access to multi-precision integer math, it
takes 15 mins to implement RSA keygen, encryption and decryption with
20 mins black box testing of each section.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Yes, you can guard against an RNG failure by use of statistical
randomness
> tests ala FIPS 140-1 or -2.
> Don Johnson
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 19 Jan 2001 16:01:53 GMT
Subject: Re: ___ECC encrypt/decrypt
ECIES is being specified in IEEE P1363a and in X9.63. This is based on
Bellare/RogawayAbdalla DHAES paper. See their paper for why it is a good
method.
Don Johnson
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: block algorithm on variable length without padding?
Date: Fri, 19 Jan 2001 09:06:00 -0700
Splaat23 wrote:
>
> Maybe I'm missing something, but if the main point of this is to
> encrypt a message without expanding it, why not pick any of the secure
> block cipher modes that generate a keystream like a stream cipher.
<snip>
No problem. Just don't forget: never use the key again.
JM
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ___ECC encrypt/decrypt
Date: Fri, 19 Jan 2001 16:20:19 GMT
In article <[EMAIL PROTECTED]>,
kctang <[EMAIL PROTECTED]> wrote:
> Dear forum,
>
> Is the elgamal type of encryption/decryption scheme still being used
> in ECC standards such as IEEE P1363 or ANSI X9.6x?
>
> If not, why?
>
> What encrypt/decryption schemes is/are being used in IEEE P1363?
> What encrypt/decryption schemes is/are being used in ANSI X9.6x?
X9.63 is not an encryption standard. It is a key exchange standard.
X9.62 is a digital signature standard. El-Gamal isn't relevent to
these.
It is no longer P1363, since it has been approved. It is just 1363
and it does allow El-Gamal, AFAIK.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: Comparison of ECDLP vs. DLP
Date: Fri, 19 Jan 2001 08:54:49 -0800
Splaat23 wrote:
> However, if speed of implementation is a factor, I _do_ choose RSA
> because in any language with access to multi-precision integer math, it
> takes 15 mins to implement RSA keygen, encryption and decryption with
> 20 mins black box testing of each section.
But not over DH/DSA. DH/DSA is easier to implement than RSA.
------------------------------
From: [EMAIL PROTECTED] (Adam Victor Reed)
Subject: Faculty Opening - Applied Cryptography, Network Security Protocols
Date: 19 Jan 2001 05:57:47 GMT
IS Faculty Position at the California State University, Los Angeles
The College of Business and Economics at the California State University, Los
Angeles is seeking to fill three tenure track faculty positions at Assistant
Professor level in Information Systems beginning Fall, 2001. An earned Ph.D.
from an accredited institution of higher education in Information Systems or a
closely related field is preferred. Evidence of publications of applied
research in the area of specialty, potential for grant generation, and the
ability to develop new courses and incorporate emerging and evolving
developments in the field are desired. Preference will be given to candidates
who are able to teach and conduct research in one or more of the following
areas: Systems Analysis and Design, Computer Communications and Networking,
Database Design, Web Application Development: HTML, Java, etc., and E-Commerce
Applications
The University: California State University, Los Angeles, a comprehensive urban
university and one of 23 campuses that comprise The California State University
system, offers programs in more than 50 academic and professional fields. The
Department of Information Systems, with approximately 700 undergraduate
students and over 100 graduate students, is one of six departments in the
College of Business and Economics.
Salary: Initial salary will be commensurate with qualifications and experience.
Substantial performance/merit increases may be earned in subsequent years.
Required Documentation: Applicants must submit the following documentation: a
letter of application; curriculum vitae; three letters of recommendation; and a
transcript from the institution awarding highest degree. Employment is
contingent upon proof of eligibility to work in the United States.
Application: Review of applications will begin on January 15, 2001 and continue
until position is filled. Address applications, required documentation and/or
requests for information to:
Dr. Parviz Partow, Chair
Department of Information Systems
College of Business and Economics
California State University, Los Angeles
5151 State University Drive
Los Angeles, CA 90032
--
Adam Reed
[EMAIL PROTECTED]
Context matters. Seldom does *anything* have only one cause.
------------------------------
From: =?Windows-1252?Q?Lu=EDs_Casanova?= <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Fri, 19 Jan 2001 17:01:54 -0000
Reply-To: =?Windows-1252?Q?Lu=EDs_Casanova?= <[EMAIL PROTECTED]>
Try this
http://www.amazon.com/exec/obidos/ASIN/0471117099/107-7063493-9997333
LC
------------------------------
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Crypting byte by byte
Date: Fri, 19 Jan 2001 18:34:08 +0100
Sorry for word game, but this can explain my need.
I'm looking for an algorthm that can code a stream byte by byte.
RC4 could be OK, but I'm looking some alternative.
particularly I've the problem to keep the 2 sides syncronized.
Any suggestion/reference will be welcome.
dex
------------------------------
From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Kooks (was: NSA and Linux Security)
Date: Fri, 19 Jan 2001 17:28:33 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Greggy wrote:
> >
> > ******************
> > --
> > 13th amendment to the US Constitution:
> > If any citizen of the United States shall accept, claim, receive,
> > or retain any title of nobility or honour, or shall, without the
> > consent of Congress, accept and retain any present, pension,
office,
> > or emolument of any kind whatever, from any emperor, king, prince,
> > or foreign power, such person shall cease to be a citizen of the
> > United States, and shall be incapable of holding any office of
> > trust or profit under them, or either of them.
> >
> > Sent via Deja.com
> > http://www.deja.com/
> ------------------------------------
> You better tell this to all Nobel Prize laureates (and and strip them
> all out of American citizenship).
>
> Usually I end my messages with the words "Best wishes".
> Sorry, in this cannibalistic case I just cannot do it.
Those who cannot endure the great burden that falls upon their
shoulders once they stare the truth in the face readily turn away from
the responsibilities that their citizenship calls for.
George Washington was a man who knew he could not accomplish the
necessary objectives on his own strength, and instead relied on God. I
also know that this truth that I share with you is too burdensome for
my own strength - I rely on God for help.
It is those that know no God that have no hope to accomplish great
things that would otherwise burden their shoulders to the grave.
--
13th amendment to the US Constitution:
If any citizen of the United States shall accept, claim, receive,
or retain any title of nobility or honour, or shall, without the
consent of Congress, accept and retain any present, pension, office,
or emolument of any kind whatever, from any emperor, king, prince,
or foreign power, such person shall cease to be a citizen of the
United States, and shall be incapable of holding any office of
trust or profit under them, or either of them.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Gordon Walker <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 19 Jan 2001 17:27:32 +0000
On Fri, 19 Jan 2001 02:16:23 -0800, David Schwartz
<[EMAIL PROTECTED]> wrote:
>> Think about it for a moment. The scheme being proposed would no longer
>> permit you to grab a serial number from a warez site or group since it
>> must be generated from your hardware (unless MS leave in backdoor
>> codes). Therefore that apparently easy means of blacklisting numbers
>> is not available to them.
>
> Huh? You're still going to have some kind of product key or something,
>otherwise how would they know whether or not you bought the software?
>The value the installer generates will contain a combination of your
>fixed 'serial number' and a hardware-dependent value.
Indeed, but that value does not allow you to install the product. That
value is sent to Microsoft who validate it and issue the actual
install key. Therefore, as I said originally, you cannot simply grab a
code off some warez site.
> Nonsense. I don't think Microsoft really cares about people installing
>software for their friend of mother-in-law.
It is unclear to me how you come to this conclusion. Microsoft's
current beta of Whistler contains a scheme that will require everyone
who uses it to go through this activation process. The installer does
not have a button labeled "I am not a mass pirate" which allows you to
bypass the step. Therefore the typical home user will be affected by
this every time their hardware changes.
>> The worst of it is the scheme won't stop the large scale pirates whose
>> cost Microsoft so much since they will either patch the OS or else
>> produce key generators. The only people it will affect are the
>> individual users giving a copy or two to their friends and in stopping
>> this insignificant trickle of piracy they will inconvenience the vast
>> majority of their customers.
>
> I don't think you understand how the scheme works. There is no key to
>generate.
Either you are hearing of its function from a different source or else
you do not understand how it works. The following is how it was
reported on the Register
(http://www.theregister.co.uk/content/4/16223.html):
"Whistler (along with Office 10) uses a combination of a CD key and a
code generated from the specific machine's hardware to generate
another code, which is then validated by Microsoft by phone or over
the Web, and you get another key which unlocks the software. You can't
use it on two different machines,* and if you change your hardware and
need to reinstall the key you have isn't valid"
Yes, there is a product key but that is insufficient to install the
product. You must contact Microsoft for each and every install,
provide them with the code the Install is showing you (generated from
the CD key and the hardware has) and then they provide you with the
actual activation key which will allow the installation to proceed.
This is the step which pirates will create a key generator to bypass.
--
Gordon
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 19 Jan 2001 18:44:20 +0100
Benjamin Goldberg wrote:
>
> John A. Malley wrote:
> > May I paraphrase the description of block balancing to make sure I
> > understand the mechanism as envisioned? And please, correct me if I
> > got this wrong.
> >
> > Given plaintext P,
> >
> > 1) divvy P into bytes as P[1], P[2], P[3] ... P[n],
> >
> > 2) build up (one at a time) blocks of size k bytes, B[1], B[2], B[3]
> > ... B[m] where m < n, and sequential plaintext bytes are assigned to
> > a given block B[i] where B[i] is the concatenation of a few plaintext
> > bytes, followed by a special byte that has 0s and 1s in it, followed
> > by bytes of all zeros or all ones - like
> >
> > P[1] | P[2] | ... | P[L] | a block of 1s and 0s | 00000000 |
> > 11111111 | ... 00000000 = B[i]
> >
> > or
> >
> > P[1] | P[2] | ... | P[L] | a block of 1s and 0s | "0" | "255" | ...
> > "0" = B[i]
> >
> > Is this an accurate description of the proposed bit balancing?
>
> Almost. It's more like
> if( P[1..L] has more 0s than 1s ) {
> P[1] | P[2] | ... | P[L] | XXXXXXX | 00000000 | 00000000 = B[i]
> Where XXXXXXXX is some number of 1s and 0s.
> } else {
> P[1] | P[2] | ... | P[L] | XXXXXXX | 11111111 | 11111111 = B[i]
> Where XXXXXXXX is some number of 0s and 1s.
> }
[snip]
I am certainly confused. What if, say, the block size is
4 bytes and one has (1) two bytes and (2) three bytes of
information which are all 0's? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Date: 19 Jan 2001 17:54:16 GMT
Subject: Re: Comparison of ECDLP vs. DLP
Splaat23 wrote and I intersperse my comments inside prefixed with DJ:
"Just because it passes statistical tests doesn't mean it's
cryptographically secure. No amount of statistical testing can prove
that a RNG is unpredictable and thus secure. For example, most every
good CSPRNG passes statistical tests, but if I know the key it is 100%
predictable until the key changes. Even the C library rand() probably
passes a bunch of tests, but it is worse than worthless.
DJ: I do not think C rand() passes the FIPS 140 tests, but am not sure and it
should not be used. As I say, security is about assurance, if you need
assurance, do the tests, if not, do not. The tests give added assurance of
conformance.
In general, this dialog has been fairly ridiculous. In any scheme,
there has to be some trust in the implementor of the scheme. Both RSA
and DLP can both be verified by the key generator after keygen is
complete to check for errors, and even if some weird error occurred
during keygen the checker will pick it up because the likelihood of the
checker having an error that will EXACTLY counter the other error is
small.
DJ: Yes, you can regen the key using other code/hw and see if you get the same
result. This can give assurance to the owner.
In the case of RSA, _that is it_. A faulty RSA key has no bad aspects
aside from not working, and it is in the keyholder's best interest to
make sure his key is valid and secure against attacks.
DJ: Just not working, this means the data from encryption is not recoverable,
for example.
DJ: I think a better statement is that it is in the best interest of a good
guy. A bad guy can make something not work for many reasons, to repudiate a
signature, to allow someone to decrypt a sensitive message while still claiming
he did not reveal it (due to a bug on his system that is not his fault), just
to cause trouble with the trust model, etc. I think it is naive to assume all
users of PKI are good guys.
In the case of
DLP, there are situations where someone else, to preserve his own best
interests, must remotely verify the validity of someone else's key.
This is just an aspect of DLP, has been solved in both interactive and
non-interactive proofs, and is one of the many differences between RSA
and DLP that keep both of them as viable methods. Personally, EC-DLP
and RSA are really almost tied, and the circumstances will totally
guide me in my choice. This is not the place to mention the
comparisons, but just search the web if you want a side-by-side
comparison.
However, if speed of implementation is a factor, I _do_ choose RSA
because in any language with access to multi-precision integer math, it
takes 15 mins to implement RSA keygen, encryption and decryption with
20 mins black box testing of each section.
DJ: You are looking at program coding speed, which is not a normal metric.
Usually of concern is speed of the operations, key gen, sig gen, sig ver, etc.
after they have been coded.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> Yes, you can guard against an RNG failure by use of statistical
randomness
> tests ala FIPS 140-1 or -2.
> Don Johnson
Don Johnson
------------------------------
** 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
******************************
