Cryptography-Digest Digest #240, Volume #9 Tue, 16 Mar 99 11:13:05 EST
Contents:
PKCS5Padding with CFB8 and DES (Augustin Volker)
Re: Finite Field with Hard Division? (Safuat Hamdy)
Re: Self-executing encryption program ("Andrew Jeffries")
Re: Test vectors for RC4 (mok-kong shen)
Re: DIE HARD and Crypto Grade RNGs. (mok-kong shen)
Sites using Global ID from verisign ("Alberty Pascal")
Re: pRNG that is "predictable to the left"? (Christoph Haenle)
Re: Cyclic attack on RSA (Bo Dömstedt)
Re: RSA Key length ([EMAIL PROTECTED])
Re: RSA in JavaScript? ("Christian Braun")
Secure Hash (new idea) ([EMAIL PROTECTED])
Re: DIE HARD and Crypto Grade RNGs. (Jaap-Henk Hoepman)
Re: Cyclic attack on RSA (DJohn37050)
PKCS5 style padding and CFB24??? (Augustin Volker)
Re: Limitations of testing / filtering hardware RNG's (Mok-Kong Shen)
Re: Certicom Benchmark (Francis Tan)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Augustin Volker)
Subject: PKCS5Padding with CFB8 and DES
Date: Tue, 16 Mar 1999 10:05:17 LOCAL
How do I pad DES/CFB8/PKCS5Padding? Do I pad 8-byte blocks or he 1-byte block
of the CFB8 mode?
"The only system that is truly secure is one that is switched off and unplugged,
locked in a titanium-lined safe, buried in a concrete bunker, and surrounded by nerve
gas and very highly-paid armed guards. Even then, I wouldn't stake my life on it."
-- Gene Spafford
Insure your privacy! Use Pretty Good Privacy!
http://www.pgpi.com/
------------------------------
From: Safuat Hamdy <[EMAIL PROTECTED]>
Subject: Re: Finite Field with Hard Division?
Date: 16 Mar 1999 10:22:38 +0100
[EMAIL PROTECTED] (Gregory G Rose) writes:
> In article <[EMAIL PROTECTED]>,
> >Am I doing something wrong? This statement only seems to be true ONLY
> >for field sizes 1, 2, 3, 5, 7 and 11. (But to be honest, I just tested
> >all field sizes up to about 30)
>
> The operative word here is "field". Fields have [...]
Greg, where's the point here? In a field of size q, q a prime power,
and x a field element != 0, x^(q-2) *always* gives you the inverse of x.
But, you cannot use simple modular arithmetik any longer when q is not a
prime (that is F_q != Z_q if q is not a prime), you have to switch to
polynomial modular arithmetik. So, no wonder that x^(q-2) failed to be the
inverse of x when q wasn't a prime.
--
S. Hamdy | All primes are odd except 2,
[EMAIL PROTECTED] | which is the oddest of all.
|
unsolicited commercial e-mail | D.E. Knuth
is strictly not welcome |
------------------------------
From: "Andrew Jeffries" <[EMAIL PROTECTED]>
Subject: Re: Self-executing encryption program
Date: Tue, 16 Mar 1999 09:43:49 GMT
<SNIP>
>> If you have a better example, then post it. If not...
<SNIP>
>Actually I hope there -is- a good self-extract tool that uses stronger
>encryption than PkZip alone does, because I could definitely use it.
<SNIP>
>So I can't offer a better example but I'm sure hoping someone else
>does. There is a market there. [P.S. My wish-list would be "it
>requires nothing more than DOS to do the decrypt..."]
I posted an announcement to alt.security.pgp and comp.security.pgp.discuss
about an upcoming, freeware, with source code application to do this. A
copy of this announcement is below. Unfortunately as a Delphi programming
company, you will require 32-bit Windows to extract the files, but at the
moment our tests are acheiving slightly better compression than WinZip, with
160-bit Blowfish encryption.
We don't know at the moment how much larger the self-extracting archives are
going to be than the normal archives, but we should be releasing a
beta-version by the end of this month.
Announcement
============
Stevenage, Herts, UK - Kwik-Rite Development has today announces plans to
produce an encrypting/compressing archive utility called Kwik-Crypt. Kwik-
Crypt will produce a multi-file archive that has been compressed then
encrypted with Blowfish using an SHA-1 password hash.
Users can either distribute just the archive file or Kwik-Crypt can create a
self-restoring file that when run on a target machine will decompress and
decrypt each file.
When Kwik-Crypt restores files (either from an archive file or by opening a
valid self-restoring archive) the user will be able to confirm :
1) The integrity of the self-restoring code (if present)
2) The integrity of each file
The most important part of the announcement, Kwik-Crypt will be released as
Freeware with full Delphi 4 source code.
Kwik-Rite Development has asked Sam Simpson is provide advice on the
cryptographic elements of the program and he has accepted.
The product is due to go into beta-testing at the end of March 1999. Any
interested beta-testers please contact us (via the alt.security.pgp
Newsgroup) for a beta-copy.
Another announcement will be made when the product is fully released.
Andy Jeffries
Kwik-Rite Development
------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: Test vectors for RC4
Date: Tue, 16 Mar 1999 10:56:17 +0100
[EMAIL PROTECTED] wrote:
>
> Well there are 256! possible session keys. And I believe the user key and
> session key have a 1:1 ratio. So that would mean it's pretty strong.
> Provided you don't use the same key twice.
I am in NO way claiming that any specific cipher is not strong, only
that the concept of strength is difficult to define satisfactorily.
But your argument that the hugeness of the keyspace implies the
better quality of an algorithm is certainly very questionable.
M. K. Shen
------------------------------
From: mok-kong shen <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Tue, 16 Mar 1999 11:07:18 +0100
Patrick Juola wrote:
> Actually, this would be quite useful if you could get the amount
> of theoretical support for this definition that K-complexity has
> for it.
>
> For example, there are some useful theorems available that state
> that Kolmogorov complexity is universal (to within a constant)
> irrespective of the particular implementation of a Turing Machine
> you use, so, for example, you get the same complexity definitions
> whether you're using a RAM or a pure Turing machine.
>
> It would be both useful and interesting if you could show that,
> for example, a particular class of encryption schemes requires the
> same amount of computational effort to break irrespective of the
> amount of cyphertext you have available -- or irrespective of
> whether you've got plaintext/cyphertext pairs. Or a proof that
> the solution to *this* encryption scheme is independent of
> the solution to *that* one. All of which are available as analogues
> for Kolmogorov complexity.
>
> It sounds to me like you're whining that a hammer won't paint the
> walls. Lots of people like hammers, lots of people use hammers,
> and if you're trying to paint the wall with a hammer, don't blame
> the designer of the hammer -- or the designer of the wall, for
> that matter. If Kolmogorov complexity doesn't appear to solve the
> problem you're interested in, then why the hell don't you get a
> different tool?
The problem I see is the following: One defines a quantity which
one can never really compute and then theorize in the 'world' in which
this quantity is (assumed to be) computable/manipulable and then 'map'
the results thus obtained into our real world. I personally doubt that
this is a genuinely valid scientific approach.
M. K. Shen
------------------------------
From: "Alberty Pascal" <pal@nospam*bsb.be>
Subject: Sites using Global ID from verisign
Date: Tue, 16 Mar 1999 11:56:25 +0100
Hi,
I'm searching any sites using the Global ID from verisign which permit
to export grade browsers to initate 128 bits ssl tunneling with
SGC compliant web servers.
TIA
--
======================================================================
pal@bsb*nospam.be
Please remove *nospam if you want to send me a mail
------------------------------
From: Christoph Haenle <[EMAIL PROTECTED]>
Subject: Re: pRNG that is "predictable to the left"?
Date: Tue, 16 Mar 1999 11:39:59 +0100
Mok-Kong Shen wrote:
>
> Christoph Haenle wrote:
>
> > The issue is that d is the secret exponent in RSA, and e is the
> > public exponent. When you have x_5, then computing x_4 is easy:
> >
> > x_4 = {x_5}^e mod n,
> >
> > since in RSA, {m^d}^e = 1 mod n for all 0<m<n. Likewise, you can
> > compute x_3, x_2, and x_1, but not x_6 for example.
>
> O.K. But can you give an example where the generator can be useful?
>
> M. K. Shen
The advantage of making it possible to compute previous values is that
the receiver doesn't have to archieve all values while he's still able
to retrieve them if needed.
For example, if you want to keep track of the numbers chosen in a
lottery for the past n years, all you need to do is store the most
recent
outcome.
-Chris.
------------------------------
From: [EMAIL PROTECTED] (Bo Dömstedt)
Subject: Re: Cyclic attack on RSA
Reply-To: [EMAIL PROTECTED]
Date: Tue, 16 Mar 1999 10:13:14 GMT
...to have a discussion, it takes a minimum of two (2) people.
I am here. The other one is You, dear Reader. Then, we need a
subject. Intelligent people may have an interesting discussion
on ANY subject. (In sci.crypt, you should not discuss off-topic
questions.) How about the following subjects?
[EMAIL PROTECTED] (Bo Dömstedt) wrote:
>A recent update on this subject (?) has been published (A5),
>where the security of RSA has been evaluated to be to low for
>defence communications.
If RSA doesn't work a substantial part of last decade's research on
protocols would be almost useless. What do RSA Data Security
think about this?
[EMAIL PROTECTED] (Bo Dömstedt) wrote:
>Another striking fact is that RSA is now officially "Snake-Oil".
>In the Snake-oil FAQ (A6) under the title "Exportable from the USA"
>we find:
>>Chances are, if the software has been approved for export,
>>the algorithm is weak or crackable.
>And according the most recent Wassenaar Arrangement
>512 bits RSA is indeed exportable (A7).
Initially, there was a discussion that a product should not be
called "Snake Oil" just because that it doesn't look like PGP.
Now, PGP looks like snake oil. Should PGP or Snake Oil FAQ
be modified? Maybe there is an error on Wassenaar Arrangement
official site? PGP does not use Public Key anymore?
[EMAIL PROTECTED] (Bo Dömstedt) wrote:
>It is well known that serious attacks on RSA are equivalent
>to factoring the modulus. Maybe factoring of 1000 bit integers
>isn't as hard as we think? Has the oldfasioned factoring
>methods (A7/A8) been improved?
To investigate the properties of shift registers we need to
factor a large number<...>. But as most post-war cipher
machines was based on shift registers, methods of factoring
such numbers was also investigated, by the cipher
guys<...>. Evidently, 1000 bit composite numbers was
factored - a very long time ago. But those factoring
algorithms doesn't work on RSA composite numbers,
right? No research took place from 1969
onwards?
Bo Dömstedt
Cryptographer
Protego Information AB
http://www.protego.se
(Hardware random number generators for sale)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA Key length
Date: Wed, 10 Mar 1999 11:16:34 GMT
> It could be fine. Check the length of the "p" and
> "q" primes that make up the 1017 bit "n". If they
> add up to 1017, you're ok. If they don't, you
> lost bits someplace and the whole system may not
> work.
The sum of the length of p and q do not give the length of n but give the
maximum possible length of n.
Example:
If p = 17 and q=19 then n = 323
p and q are both 5 bits long while n is 9 bits long. Where is my lost bit?
Neil.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Christian Braun" <[EMAIL PROTECTED]>
Subject: Re: RSA in JavaScript?
Date: Tue, 16 Mar 1999 13:18:02 +0100
Well,
I strongly believe, that any implementation of RSA in JavaScript would be
much too slow! You need to calculate with very large numbers (e.g. powers of
1024 bit numbers)!
anonymous-remailer@[146.115.234.58] schrieb in Nachricht
<7ck2bp$o51$[EMAIL PROTECTED]>...
>---BEGIN ANONYMOUS REMAILING---
>Are there any implementations of RSA in JavaScript out there?
>---END ANONYMOUS REMAILING---
>
> Remailed by 146.115.234.58 to news.rcn.com. We aren't responsible for
> any bullshit or flamage put out by this person. Report problems to
> root@[146.115.234.58]
>
------------------------------
From: [EMAIL PROTECTED]
Subject: Secure Hash (new idea)
Date: Tue, 16 Mar 1999 12:07:06 GMT
I believe I improved the randomness of the output by using better diffusion in
the induction part. I have run some simple test (2^20 4-byte tests), and have
found that all of the symbols have a 0.0039 probability with 0.16% chance of
error.
I think because of the better diffusion it will perform much better then
SHC1. You can still use 16-bit registers, but I wouldn't. In my preliminary
testing 16-bit registers got anywhere from 0.0041 to 0.0037 in the symbol
probabilities while the 32-bit got from 0.0038 to 0.0039.
Please have a look, all my crypto stuff is now organized at:
http://members.tripod.com/~tomstdenis/crypto.htm
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Jaap-Henk Hoepman <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: 16 Mar 1999 14:57:41 +0100
[EMAIL PROTECTED] (Patrick Juola) writes:
> >> For a fixed string/sequence, the time required to output that string is
> >> also fixed; the input and computing portions of the time are rather trivially
> >> reduced to zero (or a near-zero constant) by simply coding the program as :
> >>
> >> main()
> >> {
> >> printf("...");
> >> }
> >>
> >> This will, of course, output any desired string in time proportional
> >> to the length of the string; this is provably optimal for all components.
> >
> >I thought we were considering a program of the Komolgorov type which
> >I presume involve some genuine computations and not a program that
> >is written to directly print the sequence as you indicated.
>
> Well, that's the *point*. Kolmogorov complexity is defined as a
> minimum *size* of program to print out a given string. The program
> indicated above will print out the given string -- but requires
> space equal to the length of the string. For a string with substantial
> regularity to it, then there will be a program that recognizes and
> takes advantage of these regularities and does some computation. As
> a result, you'll have a program which is more computationally
> intensive, but shorter.
>
> [...]
>
> Turning the definitions around, if you want to optimize instead for
> time, you find that the upper bound on length also provides a lower
> bound for time; the more computation you do, the *slower* your program
> will run. So time-complexity -- shall I call it naive Shen-complexity? --
> is not an especially useful or meaningful measure. So you'll need to
> come up with a less naive (and unfortunately more complex) definition
> for your complexity measure.
Actually, there is such a thing as resource bounded Kolmogorov complexity where
the minimum length program is taken from all programs that use only a bounded
amount of time (as a function t of the length of the output) and a bounded
amount of (work)space (as a function s of the length of the output).
Regards,
Jaap-Henk
--
Jaap-Henk Hoepman | Sure! We've eaten off the silver
Dept. of Computer Science | (when even food was against us)
University of Twente | - Nick Cave
Email: [EMAIL PROTECTED] === WWW: www.cs.utwente.nl/~hoepman
PGP ID: 0xFEA287FF Fingerprint: 7D4C 8486 A744 E8DF DA15 93D2 33DD 0F09
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Cyclic attack on RSA
Date: 16 Mar 1999 14:34:05 GMT
Please give the exact reference for a paper saying that RSA security was too
low for defense communications. Thanks
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Augustin Volker)
Subject: PKCS5 style padding and CFB24???
Date: Tue, 16 Mar 1999 15:40:00 LOCAL
I have a serious problem concerning CFB mode and padding.
I have been reading the DES specification (FIPS PUB 81) but it only describes CFB mode
without
padding. My problem is the following.
Consider an 8-byte block cipher (e.g. DES) in CFB24 mode using PKCS5 style padding.
This is
implemented in Sun's SunJCE provider which comes with the JCE1.2 from Sun.
The question is what the relevant block size for the padding is. Is it 8, since DES
has a
block size of 8 or is it 3, since we are operating in CFB24 mode?
Let's have a look at an example.
Consider an input block of length 24. 24 is both a multiple of 8 and of 3, so we will
have to pad a
whole block wether we use 3 or 8 as the relevant block size.
1. If we consider 3 the relevant block size, I append 3 bytes containing the value 3
to the
plaintext which can be encrypted in CFB24 since they form a full block (with respect
to the
relevant block size of 3). So this works.
2. If we consider 8 the relevant block size, I have to append 8 bytes containing the
value 8 to the
plaintext. So now we have to encrypt 8 bytes. This cannot be done in CFB24 mode, since
8 is no
multiple of 3. A possibility would be to encrypt this last 8-byte-block using ECB
instead. But this
is undesirable.
SunJCE implements 2. but doing the final block with CFB24. Thus, when you input 24
bytes to their
DES/CFB24/PKCS5Padding cipher, you get an exception, saying:
javax.crypto.IllegalBlockSizeException: Input length (with padding) not multiple of 3
bytes
When you use ECB instead you would get a ciphertext, but then decryption doesn't work
anymore for
the following reason:
Since we *might* have an 8 byte padding at the end, we need to keep 3 full blocks of 3
byte in
buffer. So you would get the first ciphertext block after you feed the cipher 12
bytes. This is not
the reason CFB24 is implemented for. CFB24 should return a block of ciphertext,
whenever it's fed a
block of plaintext.
I would really appreciate any comments on this issue.
Volker
"The only system that is truly secure is one that is switched off and unplugged,
locked in a titanium-lined safe, buried in a concrete bunker, and surrounded by nerve
gas and very highly-paid armed guards. Even then, I wouldn't stake my life on it."
-- Gene Spafford
Insure your privacy! Use Pretty Good Privacy!
http://www.pgpi.com/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Tue, 16 Mar 1999 16:36:13 +0100
Mark Currie wrote:
> Here is one way of doing it:
>
> Once you have decided on the real time tests to be applied, if a rejection
> occurs, keep discarding the RNG stream until it passes the tests. Normal
> operation need not be affected. By using a set of statistical counters, one can
> set up thresholds after which the RNG is deemed faulty. i.e. if more than X
> rejections occur within Y time frame, halt usage and report failure of RNG.
> Multiple threshold levels can be used. i.e. number of rejections per
> second, per minute, per day, etc.
>
> We both agree on the need detect failures. The real difficulty is in deciding
> on the types of real time tests to be used and what impact they have on the
> entropy if we discard rejected values. In my original posting, this was the
> area that I was hoping to get feedback on.
I am afraid that no selection of tests to be used can be free of
subjectivity, i.e. the decision can't be arrived at by purely
scientific means. No test can be fool-proof. For otherwise one
needs only firmly integrate that test into the system and would
thus be able to obtain a perfect system. I suppose that many
people have applied a number of tests on random sequences they
use in applications but these experiences are hardly available to
the general public because such results are normally not deemed to be
of sufficient value for publication in papers. I think this is a pity.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Francis Tan)
Subject: Re: Certicom Benchmark
Date: Tue, 16 Mar 1999 14:51:50 GMT
Going back to the benchmark result from Certicom IPSEC implementation
163 bit ECDH 239 bit ECDH
Key Generation 4.90ms 9.60ms
Shared Secret 4.75ms 10.00ms
Does anyone know why the shared secret is faster than the key
generation in 163 bit ??
I assume that in key generation, we are performing a scalar
multiplication of a fixed point, while in shared secret it is a scalar
multiplication of a random point since the public key can varies.
Shouldn't the key generation be faster since there are numerous
efficient method of scalar multiplication with precomputations?
Thanks.
Francis Tan
------------------------------
** 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
******************************
