Cryptography-Digest Digest #868, Volume #8 Fri, 8 Jan 99 22:13:03 EST
Contents:
Re: OCX/DLL wanted ("Morten H. Nielsen")
example with concrete numbers of blind signature (sos)
Re: Factoring ("Yves Gallot")
Re: On the Generation of Pseudo-OTP (wtshaw)
Re: RSA question ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP (Paul L. Allen)
A method on finding the cheater in sharing scheme. (xlzhu)
Re: ScramDisk - password size - high ASCII (wtshaw)
Re: Triple DES with CBC (DJohn37050)
Attention: This is an encoded message????? (EvanPic)
Re: On leaving the 56-bit key length limitation ([EMAIL PROTECTED])
Triple DES with CBC ("Steven H. McCown")
Re: Learn Encryption Techniques with BASIC and C++ (CryptoBook)
Re: RSA-Modulus decomposition (Robert I. Eachus)
Re: On leaving the 56-bit key length limitation (wtshaw)
----------------------------------------------------------------------------
From: "Morten H. Nielsen" <[EMAIL PROTECTED]>
Subject: Re: OCX/DLL wanted
Date: Fri, 8 Jan 1999 22:23:17 +0100
Try this link One of the BEST
http://sevillaonline.com/ActiveX/
Jonas Westberg skrev i meddelelsen <774vgh$c8v$[EMAIL PROTECTED]>...
>Please let me know if you know of any Components that can be used in Visual
>Basic applications (OCX/DLL).
>
>- Public Key Algorithm (RSA key generation, encryption and signing)
>- Secret Key Algorithm (free block- or fiestelchipher like CAST)
>
>Thanks....
>
>Jonas Westberg
>[EMAIL PROTECTED]
>
>
>
>
------------------------------
From: sos <[EMAIL PROTECTED]>
Subject: example with concrete numbers of blind signature
Date: Fri, 08 Jan 1999 23:25:25 +0100
For a small treatise I am looking for an example with concrete numbers
of blind signature.
I think I understand all the formulas, but I can not achieve a
reasonable results.
All publications I found only give some hints how it works and what the
formulas are. Maybe there you can give me an internet location that can
help me.
Please mail me directly.
Soeren Schmidt
------------------------------
From: "Yves Gallot" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Factoring
Date: Sat, 9 Jan 1999 00:19:18 +0100
Thank you very much for your excellent program!
Yves
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On the Generation of Pseudo-OTP
Date: Fri, 08 Jan 1999 16:32:11 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>
> However the context of my proposal is that one can only get
> 56-bit cryptos (and very likely only software). So I think that even
> a not so good approximation of an OTP helps to a certain degree, for
> it can be used in conjunction with a 56-bit crypto software and
> enhance its strength. We have to collect all useful things and
> combine them, so that those who can only get 56-bit cryptos (those
> outside of the 33 countries) can still obtain adequate security
> in their communications.
>
All it takes is a little creative chaining to even if single algorithms
are 56 bit cryptos. Consider what intermediate steps might be needed to
strip away headers that anounce what algorithm was used. The fact being
that it is not easy to determine that a 56 bit limit was surpassed or
wasn't, except that the hall-monitor might be upset that their techniques
of retreving plaintext did not work. No, a 56 bit limit does not do much
in itself, which is the point.
Look next for severe restrictions for using only very few algorithms.
--
If government can make someone answer a question as they want him to, they can make
him lie, then, punish him for not telling the truth. Such an outrage constitutes
entrapment.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA question
Date: Fri, 08 Jan 1999 21:56:35 GMT
The security of RSA is conjectured to be based upon the Integer Factorization
Problem (IFP), but this link has never been proved.
Recently, a paper “Breaking RSA may not be equivalent to factoring” by D.Boneh
& R.Venkatesan published in Eurocrypt '98 shows some classes of the RSAP which
are not equivalent to the underlying IFP.
It _may_ be possible to break RSA without factoring...
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.
In article <9DB141BB95ACD978.552D4BEF2C5C8648.1961F2B1F78F3098@library-
proxy.airnews.net>,
Rx Video <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've recently read through the theory on RSA algorithm. I just wanted to
> make sure if the factorization of the N (modulus) number is the keystone
> of its security ?
> p*q=N - I have not tried to compute all the possible values for p and q
> with known N, but the approach to find those values would be to divide N
> by i, with i increasing with every step (or changing i to the next prime
> number), until one of p or q is found. I do not know how difficult that
> task is for sufficiently long N. I would appreciate a comment on this
> one.
> Sincerely yours,
>
> Martin
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Paul L. Allen)
Subject: Re: On the Generation of Pseudo-OTP
Date: Fri, 8 Jan 1999 22:51:22 +0000
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (R. Knauer) writes:
> On Fri, 8 Jan 1999 18:44:27 +0100, <[EMAIL PROTECTED]>
> wrote:
> >The main problem is to make such a device statistically good or we
> >wouldn't get an unbreakable cipher.
>
> A TRNG has only one "statistical" property, namely that it is capable
> of outputting all sequences of a given finite length equiprobably.
So far, so good.
> That, however, is not verifiable - not even "statistically". The best
> you can do is test a TRNG to see if it does something which violates
> its prime directive, like output all 0s in worst case.
Whoops! You can only check a finite length of output sequence. And it
is perfectly possible for a working TRNG to generate a series of zeroes
for whatever length of finite output sequence you care to postulate.
Yes, if I see the output is a million zeroes I will suspect that the
generator is broken. But it *could* really be random output and the
very next term in the sequence is non-zero. You have no way of knowing
for sure - that sequence of a million zeroes is no less likely than
any other sequence of a million digits.
--Paul
------------------------------
From: xlzhu <[EMAIL PROTECTED]>
Subject: A method on finding the cheater in sharing scheme.
Date: Sat, 09 Jan 1999 08:37:30 +0800
Reply-To: [EMAIL PROTECTED]
As we know, in the original sharing scheme, users can not find
who is cheater if some of user gave out a fake shadow and
want to use it to cheat other users.
There is a method to find the cheater. When we calculate
the shadow "Si" and give it to one of user "Ui". we also make
the H(Si) public, where H(.) is a public hash function.
When some of users want to reconstruct the secret. They give out
their shadow "Si' " s. And each other calculate H(Si'). If it is not
equal to the H(Si), the user Ui is a cheater.
Is it a good method?
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: ScramDisk - password size - high ASCII
Date: Fri, 08 Jan 1999 16:39:07 -0600
In article <[EMAIL PROTECTED]>, Jim Dunnett wrote:
> On Fri, 08 Jan 1999 10:52:51 GMT, [EMAIL PROTECTED] wrote:
> >
> >I can confirm that ScramDisk uses a hash (SHA-1 to be specific) to
compress an
> >arbitrary length passphrase into a fixed width 160-bit digest.
I think you said it all, in order to *compress*, your arbitrar length
passphrase must be at least longer that that, or it is not compressed at
all. It is OK to use short passphrases, as long as the user knows that
they are not apt to give good security.
>
> So making it ridiculously long does not increase the
> security by that much.
>
> The structure of the passphrase is more important than
> its length as such.
Both length and complexity can be important; it all depends on the end
result and the potency of the two qualities in it.
--
If government can make someone answer a question as they want him to, they can make
him lie, then, punish him for not telling the truth. Such an outrage constitutes
entrapment.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Triple DES with CBC
Date: 9 Jan 1999 01:18:58 GMT
The output ciphertext of the third encryption is XORed with the input
plaintext. This is sometimes called "outer CBC" This is what is specified in
X9.52 Triple DES Modes of Operation
------------------------------
From: [EMAIL PROTECTED] (EvanPic)
Subject: Attention: This is an encoded message?????
Date: 3 Jan 1999 15:33:00 GMT
Did I miss something? Now all of the sci.crypt posts start with this header
and the following text is encoded/scrambled/? Would appreciate info on what
is going on.
Regards,
Evan.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On leaving the 56-bit key length limitation
Date: Fri, 08 Jan 1999 23:50:24 GMT
In article <7755in$3vj$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <774mjg$n49$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>
> >
> > Consider the situation in which the message space has several
> > plausible messages, but the conditional probabilities, given the
> > ciphertext, show that "Attack at dawn with 3000 men." has a
> > probability of 0.599999, and "Attack at dawn with 3006 men"
> > has a probability of 0.399999. Using Shannon's formula for
> > entropy, I calculate the equivocation of the plaintext is
> > 0.97 bits. Shannon defined the unicity distance as the number
> > of intercepted characters for which the equivocation in the
> > plaintext is very close to 0. 0.97 bits is not very close to
> > zero, therefore unicity has not been reached.
> >
> > I claimed that an attacker may get useful information from
> > the ciphertext even if he does not have enough ciphertext to
> > reach unicity. You, Ed, stated that I was wrong. The above
> > example is of course contrived, but nevertheless, the
> > conditional probabilities are possible. The attacker does
> > not have enough ciphertext to reach unicity. The attacker
> > does obtain a great deal of useful information from the
> > ciphertext. My claim that you quoted above, "A cryptanalyst
> > may still get large amounts of useful information." is true.
> >
>
> Bryan:
>
> Let us re-start here and recall that I used DES to exemplify some of my
> arguments.
>
> I agree with you that you can define unicity in such a way as to make the
> phrases "Attack at dawn with 3000 men." and "Attack at dawn with 3006 men"
> still shorter than the length required by your definition of unicity.
>
> I also agree you could define pi to be 3.
>
> However, both would be useless exercises because they fail to reflect the
> reality behind the concepts. When Shannon defined unicity he was struggling
> to define a concept -- which goes far beyond a mere expression of it as n =
> H(K)/D.
>
> Let me make my declaration precise. Unicity is (exactly in Shannon`s sense) a
> fundamental limitation to the least amount of plaintext which can be uniquely
> deciphered from the corresponding ciphertext -- given *unbounded* resources by
> the attacker. The attacker can even hire you ;-)
>
> Now, as you say that "Attack at dawn with 3000 men." and "Attack at dawn with
> 3006 men" cannot be decided by your system and, "therefore unicity has not
> been reached" -- then my conclusion is that you have left reality.
>
> Why? Because if you are using DES (as I used, so I assume that in order to
> discuss my results you would need to also use DES) then the unicity-5
> distance of DES is 3 letters as I argued -- in your case, "Att". Certainly
> your phrases are much longer than DES unicity-5, so I could break into your
> DES key with only those 3 letters and then unambiguously decipher your whole
> long message. This means that I could have uniquely chosen which message was
> correct.
>
This is not necessiarly true. If you recover the "Att" then there
is a large chance that you got the correct solution. But you still
may not have the right solution the rest of your decryption could
be junk. But I think it would be very hard not impossible but
dam close to get two message that decrypt to ASCII characters so
that both decryptions make sense with DES.
What does not make sense is the assigning of 2 different
probabilites to 2 possible out come. If one key decrypts to
meassage A and another decrypts to possible message B and
if both meaningful then either is equally possible. Further more
one would never keep trying more keys once a readable solution
was found. Since it would be very very unlikely another case
would exist.
If you are using scott19u and you have short message less than
a few thousand characters. There are so many possible readable
ascii messages a file could decrypt to that you don't have to
worry about someone finding a key since most keys they could
find would lead to a false soultion. What I am trying to say
is in the computer age why would anyone use DES.
> But, you say you could not -- again, you may say whatever you desire but the
> question is whether it corresponds to reality.
>
> For example, can you show me the DES ciphertext you used, to affirm that
>
> > conditional probabilities, given the
> > ciphertext, show that "Attack at dawn with 3000 men." has a
> > probability of 0.599999, and "Attack at dawn with 3006 men"
> > has a probability of 0.399999.
>
> ???
He would need other out side information to give anything
besides .5 assumming the VERY HIGHLY unlikely chance that
this most likely unreal situation occurs. For example
maybe the whole army was 3006 and you had a some info
on a some chance deaths that 6 men where killed with a
car bomb and you are not sure if you killed his troops
or some poor peasants but you have some satsical info
on the bombing that couls change the .5 .5 or .599 .399
or what ever. Hell makes as much since as rest of fairy
tale.
A more likely possiblity is that it decrypted to 3000
but when earler messages where decrypted it was found
that numbers of acttaul attacks some times had 6 more
men and that using results of old data you realize the
enemy may have meant 3006. You know the ratio from earlier
results but some patteren in text lets enemy know what the
real number is. It is just that you don't know the trick yet.
Hell why not.
>
> I affirm this is not possible with DES. And, one cannot just invent
> "features" to support e-mail discussions. This may be useful in rec.humor but
> not here --a technical discussion group.
>
> Now, in the case you tell me you did NOT use DES in your "example" then I say
> that is firstly a lack of basic method -- since you cannot compare apples with
> speedboats -- also perhaps useful in rec.humor but not here. Second, I ask you
> to please produce the exact ciphertext, the cipher and the key that leads to
> such "example".
>
> Otherwise, it is just so simple -- define pi to be 3 and next thing you know
> you can start to criticize much more people, not just me.
>
> In the absence of supporting evidence for your "example" that we can discuss
> not as a poker hand, I guess you can start to try to understand what I really
> wrote in the posting before confusing issues before this group.
>
> Cheers,
>
> Ed Gerck
>
> ______________________________________________________________________
> Dr.rer.nat. E. Gerck [EMAIL PROTECTED]
> http://novaware.com.br
> --- Meta-Certificate Group member -- http://www.mcg.org.br ---
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Steven H. McCown" <[EMAIL PROTECTED]>
Subject: Triple DES with CBC
Date: Fri, 8 Jan 1999 17:53:18 -0700
Hi,
I have a question regarding Triple DES. Numerous sources describe Triple
DES as:
E(K3,D(K2,E(K1,x)))
and
D(K1,E(K2,D(K3,x)))
RSA has offers a Triple DES with Cipher Block Chaining (CBC) mode in their
BSAFE product. Given the above interpretation of Triple DES, how is the CBC
process applied? It would seem that since the process was reversed, the
actual Init Vector would be applied last and that the starting CBC would not
yet have been deciphered. Any ideas on how this is done? Or is there a
better method than CBC for Triple DES?
Also, the sci.crypt FAQ that I found was dated 1994. Where can I find the
current FAQ?
Thanks,
Steve McCown
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (CryptoBook)
Subject: Re: Learn Encryption Techniques with BASIC and C++
Date: 09 Jan 1999 01:03:21 GMT
In article <7765pm$2cj$[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes:
> Does it cover any modern C ones ... or just the old stuff.
The focus is definitely on classical cryptography. Chapter 8 discusses
Public Key Cryptography but does not include any programs.
------------------------------
From: [EMAIL PROTECTED] (Robert I. Eachus)
Crossposted-To:
alt.privacy,alt.security,alt.security.pgp,comp.security.pgp.discuss,talk.politics.crypto
Subject: Re: RSA-Modulus decomposition
Date: 09 Jan 1999 01:06:33 GMT
[EMAIL PROTECTED] wrote:
> It is very easy to find decomposition of a modulus to it’s
> primes. Let n=pq be a modulus. Let m be a least message for which
> m^2 mod n = m. Then m-1 is p or q.
I should probably ignore this but...
If m^2 mod n = m, then m^2 - m mod n = 0 and (m-1) * m = 0 mod n.
This is true if m = 0 or 1, or if one of p or q is a factor of m.
(The other must be a factor of m-1.) So if this situation occurs, you
can find GCD(m,n) and find a factor of n.
However, don't worry. If p and q are prime, a number chosen at
random between 1 and n has a 1/p + 1/q chance of dividing n, but it
only has a 2/n chance of fulfilling this property. For example for n =
77 the two values of m with this property are 22 and 56. As you can
see the sum of the two is n + 1, so once you find one, finding the
other is trivial. But I don't know of an easy way to find the
solutions, even given p and q. (Well for small n, it isn't too
difficult. First find the two prime factors of n ;-) then count two
registers up by p and q respectively, only adding to the smaller
register until the registers differ by one.)
All this is lots of fun if you like Number Theory, but it doesn't
have any practical application to factoring the product of two primes
as far as I can see.
--
Robert I. Eachus
with Standard_Disclaimer;
use Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: On leaving the 56-bit key length limitation
Date: Fri, 08 Jan 1999 12:56:55 -0600
In article <7743gu$7du$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> That seems to imply a two-part test: a decryption is valid
> if it's alphanumeric, but the analyst will reject it if it's
> not sensible text.
>
> In Shannon's model that doesn't happen. The probability
> distribution of the message space (or the analyst's
> estimate of it) is the sole criteria for grading candidate
> decryptions. If 'Dxc99OVq3 rzx$jP=W' has negligable
> probability, then it's not a valid decryption. If it has
> significant probability, then the analyst will not reject
> it.
It would depend on the circumstances. Addition levels of encryption might
be incorporated into the algorithm. If Shannon's model is insufficient to
handle such circumstances, it is insufficient for anything but anything
but single layer algorithms.
So much is in interpretation and hunches that breaking the unknown
algorithm can be more art than science, which doesn't make machine
operators too happy.
--
If government can make someone answer a question as they want him to, they can make
him lie, then, punish him for not telling the truth. Such an outrage constitutes
entrapment.
------------------------------
** 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
******************************
