Cryptography-Digest Digest #123, Volume #10 Fri, 27 Aug 99 19:13:03 EDT
Contents:
Re: Key to Ciphertext Ratio's ([EMAIL PROTECTED])
Re: receiving a piece of message (Frank Gifford)
Re: RSA and Microcontroller ([EMAIL PROTECTED])
Re: Freeware windows public key encryption DLLs? ([ Dr. Jeff ])
Re: Key to Ciphertext Ratio's ([EMAIL PROTECTED])
Re: NEW THREAD on compression (Mok-Kong Shen)
Re: OT -- but you ain't gonna believe this (Greg)
Re: How to apply for security clearance? (Bob Silverman)
Re: receiving a piece of message (Paul Koning)
future of RSA and hash algorithms (bicakci)
Re: NEW THREAD on compression (John Savard)
Re: SHA-1 OID (bicakci)
Re: 512 bit number factored (Robert Harley)
Re: Can americans export crypto when in another country? (SCOTT19U.ZIP_GUY)
Re: Can americans export crypto when in another country? (SCOTT19U.ZIP_GUY)
Re: NEW THREAD on compression (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key to Ciphertext Ratio's
Date: Fri, 27 Aug 1999 17:15:32 GMT
[EMAIL PROTECTED] wrote:
> [...] Assuming we're using a block cipher,
> [...] IDEA
> [...] and we keep the plaintext constant.
[...]
> Ideally, there's
> no such thing as a bad key, so we will assume that no key will encrypt
> to anything resembling the plaintext,
Bad assumption. If IDEA behaves as we hope, then
with high probability there is some key that will
encrypt the fixed plaintext block to itself.
[...]
> Now, there are 2^64 different ciphertext permutations. Since we are
> assuming that there are only good keys, there are somewhat less than
> that.
I'm not sure what you're talking about. There exist
(2^64)! permutations of 64-bit blocks. A block cipher
with a 128-bit key can generate 2^128 different
permutations. Where does 2^64 come in?
> With these assumptions, is it possible that two or more key's
> encrypt the same plaintext to identicle ciphertext's?
It's not clear what you are asking. Here are some
answers anyway.
Is there some plaintext x and keys
k1 and k2 such that E(x, k1) = E(x, k2)?
Yes.
For arbitrary x, are there keys k1 and k2
such that E(x, k1) = E(x, k2)?
Yes.
Are there keys k1 and k2, such that for all x,
E(x, k1) = E(x, k2)?
Probably not. For a random cipher, we would not
expect it. Having "equivalent keys" is considered
a defect in a cipher.
> Also, in this
> example there are 2^128 different permutations of the key, thus the
> problem is further compounded.
There are 2^128 keys. What are "permutations of the
key" and why are there this many?
> 3. Can this be exploited? Certainly it could make a brute-force
attack
> much easier if one gets lucky.
Getting lucky makes it easier.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: receiving a piece of message
Date: 27 Aug 1999 15:34:23 -0400
In article <7q6j7o$nn2$[EMAIL PROTECTED]>,
Keith A Monahan <[EMAIL PROTECTED]> wrote:
>I wrote,
>
>: >Gary,
>: >
>: >So, if its ECB(electronic code book) only mode, he is safe -- because there
>: >is a one to one mapping of plaintext -> ciphertext but any of the other
>: >modes that involve chaining or feedback require the previous ciphertext
>: >block to properly set the IV , in which case, if he does not have
>: >he would be screwed.
>: >
>: >Right?
>: >
>
>dscott wrote,
>
>: No your WRONG. THE IV only effects the next BLOCK in standard encryption.
>: It is designed that way. And most people like you are lead astray. It is very
>: very easy to test this.
>
>When you say standard encryption, are we including CBC in that description?
>Because most of the CBC implementations I have seen look like this for the
>CBC decryption function.
>
>
>oldiv = original first IV
>
>for (length=0 to bufferlength)
>{
>
> newiv = data = srcbuffer // ciphertext
>
> ECB_Decrypt(data, key)
>
> outputbuffer = data xor oldiv // plaintext after xor
>
> oldiv = newiv
>}
>
>So looking at this function, you need to have the ciphertext block prior
>to the current block in order to have the iv to decrypt the current block.
>
>Without the oldiv, the very first(and subsequent) decryption(s) would
>fail.
Let's follow the code with a bad IV:
First block gets correct data input and encryption. It is XORed with the
bad IV, for an incorrect output.
Second block gets correct data input and encryption. It is XORed with what
was the input to the first block (which was correct). The output for the
second block is correct. It's easy to see that other blocks are correct also.
You should try it and see it happen. CBC has a self-correcting property
so that only two blocks get mangled instead of everything from that point on.
If "they" wish to brute-force your message, they only need a few blocks of
your message, not the entire thing. If you were forced to brute force a
message encrypted by David's program, you would need to work on the entire
message - regardless of its length.
-Giff
--
Too busy for a .sig
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RSA and Microcontroller
Date: Fri, 27 Aug 1999 17:58:10 GMT
Ryan Phillips asked:
> This is just a research project (for now), but is it possible to put
RSA
> Encryption and Decryption into an Intel compatible 8031 or 8051
> microcontroller?
Yes, if you have enough XRAM.
If you use a public exponent of 3 (or better yet use
Rabin-Williams with exponent 2) then you can get
encrypt and verify operations down to a few seconds.
Private key operations will take a long time,
probably on the order of an hour.
> Also, if it is possible is there any sourcecode freely available?
I don't know of any.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] ([ Dr. Jeff ])
Subject: Re: Freeware windows public key encryption DLLs?
Date: Fri, 27 Aug 1999 12:02:25 -0700
In article <[EMAIL PROTECTED]>, matt <[EMAIL PROTECTED]> wrote:
>Anyone know of any good freeware Dlls/Delphi components which can
>implement public key encryption, and digital signatures? Any secure
>algorithms are OK.
If they're freeware, how can you be assure of their security?
--
Dr. Jeff is not common so don't expect common courtesy from him.
If you don't like me, bite me. Be warned, however, I may bite back!
((N)) ((I)) ((T)) ((A)) ((L)) ((L)) ((I)) ((C)) ((A))
((F)) ((A)) ((N))
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Key to Ciphertext Ratio's
Date: Fri, 27 Aug 1999 19:47:27 GMT
In article <7q6h3v$rgt$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > [...] Assuming we're using a block cipher,
> > [...] IDEA
> > [...] and we keep the plaintext constant.
> [...]
> > Ideally, there's
> > no such thing as a bad key, so we will assume that no key will
encrypt
> > to anything resembling the plaintext,
>
> Bad assumption. If IDEA behaves as we hope, then
> with high probability there is some key that will
> encrypt the fixed plaintext block to itself.
>
> [...]
> > Now, there are 2^64 different ciphertext permutations. Since we are
> > assuming that there are only good keys, there are somewhat less than
> > that.
>
> I'm not sure what you're talking about. There exist
> (2^64)! permutations of 64-bit blocks. A block cipher
> with a 128-bit key can generate 2^128 different
> permutations. Where does 2^64 come in?
Sorry. I meant that there are 2^64 possible ciphertexts.
>
> > With these assumptions, is it possible that two or more key's
> > encrypt the same plaintext to identicle ciphertext's?
>
> It's not clear what you are asking. Here are some
> answers anyway.
>
> Is there some plaintext x and keys
> k1 and k2 such that E(x, k1) = E(x, k2)?
> Yes.
>
> For arbitrary x, are there keys k1 and k2
> such that E(x, k1) = E(x, k2)?
> Yes.
>
> Are there keys k1 and k2, such that for all x,
> E(x, k1) = E(x, k2)?
> Probably not. For a random cipher, we would not
> expect it. Having "equivalent keys" is considered
> a defect in a cipher.
>
> > Also, in this
> > example there are 2^128 different permutations of the key, thus the
> > problem is further compounded.
>
> There are 2^128 keys. What are "permutations of the
> key" and why are there this many?
Again, sorry. I meant that there are 2^128 different keys. This all
sounded right in my head last night.
>
> > 3. Can this be exploited? Certainly it could make a brute-force
> attack
> > much easier if one gets lucky.
>
> Getting lucky makes it easier.
True.
>
> --Bryan
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: NEW THREAD on compression
Date: Fri, 27 Aug 1999 23:11:42 +0200
SCOTT19U.ZIP_GUY wrote:
>
.....................
> Compression is just the opposite. Thanks for making me
> take a longer look. I will post new code shortly. But if you
> see an error in my logic let me now since it is I hope complete.
I don't exclude that my current thinking is biased towards my own
proposal and hence may be incorrect. But I conjecture that there
could possibly be a situation that is difficult for your scheme to
handle in a way quite analogous to the case of the file C consisting
of 00000000 00000000 that has forced me to introduce the 'random
feature' (admittedly rather artificial) in order to ensure
consistency in ALL situations. I have not spend much thought about
my conjecture but like to suggest that you take the following into
consideration, since you are currently reviewing you program code
anyway:
Let there be defined:
C1 = 11111111
C2 = 11111111 11111111
C3 = 11111111 11111111 11111111
Could your program decompress these to D1, D2 and D3 and then
compress back to C1, C2 and C3 without difficulties?
M. K. Shen
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: OT -- but you ain't gonna believe this
Date: Fri, 27 Aug 1999 21:09:02 GMT
I may have gotten one, I don't know. I never bother to read anything
that I cannot immediately identify as friendly communication from
someone I know.
--
Red Dawn- "What makes us better than them?" "We live here!"
Wallace on Brave Heart- "While you stand around and bicker,
I am going to take the fight to the [king's back yard]."
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: How to apply for security clearance?
Date: Fri, 27 Aug 1999 19:15:08 GMT
In article <7q6e65$pbc$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> and how much it cost for the clearance?
You don't apply. Noone does.
Your employer, assuming that your employer works on classified
projects, and assuming that your work requires classified access,
applies for you. The cost is picked up by whatever agency or
branch of government (e.g. the Navy) is sponsoring the project.
--
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/
Share what you know. Learn what you don't.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: receiving a piece of message
Date: Fri, 27 Aug 1999 17:04:26 -0400
Gary wrote:
>
> Depends on the encryption algorithm (usually the mode its run in) and
> whether
> the data was compressed before encryption.
>
> Only if each of the seperate blocks of a plain text message were
> independently
> enciphered then you could decipher the complete blocks within the partial
> message.
More precisely, it depends on the error propagation
properties of the mode. ECB has none, so you can recover
the entire partial message. OFB also has none, but you have
to know at what cycle to start. If you do (e.g., you know
the starting IV and the number of missing blocks) you can also
recover the whole message; if not, you can recover none.
In CBC each block requires the previous cipherblock to decrypt
correctly, so if you have a partial message you lose the
first block but you will be able to read all the rest.
paul
------------------------------
From: bicakci <[EMAIL PROTECTED]>
Subject: future of RSA and hash algorithms
Date: Fri, 27 Aug 1999 15:18:01 -0700
Hello,
In the future let's say 10 years later, to provide reasonable security
(here you may argue on the word reasonable, what I mean is as secure as
today's 1024 bit RSA and 128 or 160 bit hash algorithms like in MD5 and
SHA1) what needs to be the bit length of RSA and hash algorithms?
Any comments preferably with technical supporting arguments would be
greatly appreciated. Thanks.
Kemal
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NEW THREAD on compression
Date: Fri, 27 Aug 1999 22:43:39 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote, in part:
>He then decompresses C to D and compresses D to C1. If C1 is not
>identical to C (this comparison can be done automatically without
>human intervention!), he knows that K is certainly wrong.
Yes, it can be done automatically, even though it involves the whole
message.
It's a good new idea, perhaps, but I wonder if it can be done without
compromising the _old_ ideas about how compression should work for
encryption.
What I was talking about were the old ideas: how compression can be
designed to frustrate, as well as possible, a ciphertext-only attack
by removing redundancy.
This new idea of Mr. Scott's, as you describe it, is about how
compression, plus padding to bring the compressed text to a byte
boundary, can be prevented from aiding a brute-force search.
I'm not sure this is worth worrying about: about 1/8 of the possible
decrypts are going to pass this test for a "conventional" system like
mine, and so an attacker relying on the compression scheme to perform
a brute-force attack is going to have a nasty surprise.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: bicakci <[EMAIL PROTECTED]>
Subject: Re: SHA-1 OID
Date: Fri, 27 Aug 1999 15:50:53 -0700
> I would like to know the (asn1) Object Identifier for SHA-1 and/or a
> pointer to where I can find that out.
> Can anybody help me?
1 2 840 113549 1 1 5 sha1WithRSAEncryption
1 3 14 3 2 26 sha1
Look at the following URL for more info.
http://www.columbia.edu/~ariel/ssleay/asn1-oids.html
Kemal
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: 512 bit number factored
Date: 28 Aug 1999 00:53:51 +0200
Don Johnson writes:
> >Practical experience only confirmed estimates after those estimates
> >were downgraded to take the new algorithm(s) into account.
>
>Yes, these were new insights, which is EXACTLY the purpose of the ECC
>challenge, to give an practical example of what is thought to be a
>hard problem and see how hard is really is.
Indeed, and thank you to Certicom for organising the challenge.
ObPlug: I suppose this would be a perfect opportunity to mention that
a project is starting to solve the seventh challenge problem, ECC2-97.
Anyone interested in participating can head over to:
http://pauillac.inria.fr/~harley/ecdl6/readMe.html
All that's required is CPU time, a C compiler and a Unix-like O.S. (or
WinNT). The prize, if we win it, will be mostly donated to the Free
Software Foundation.
Bye,
Rob.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 23:34:46 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(wtshaw) wrote:
>In article <[EMAIL PROTECTED]>, "Trevor Jackson, III"
><[EMAIL PROTECTED]> wrote:
>
>> Then the bureaucrats ignore the letter and spirit of the law and create the
>> regs.
>>
>> Then the enforcment officers ignore the regs and do what they think best.
>>
>I find it strange if not amusing that cryptographers from the US, civilian
>and government, travel frequently to foreign locations where they share
>their thoughts and ideas with other foreigners. Indeed, even the
>government had one meeting of the AES in Rome last Spring, and I might
>add, adjacent to a Fast Encryption Workshop.
>
>If the regs as existing amounted to a hill of beans, all of those folks
>would be in trouble, the government does have a hard list of who was
>there, but, as you say, it is easy for bureaucrats to waive the regs
>whenever they damn well want to, and to threaten anyone else with severe
>penalities for making similiar logical choices about their own conduct
>whenever they want to amuse themselves about the concept of having freedom
>of expression.
>
>In short, the government presents a poor example in yet another case, but
>I understand the turf wars involved as well. It is inconceivable that a
>court would not weigh the government's nonchalance in these areas when the
>same government attempts to selectively turn the screws to punish someone
>it does not like.
It is no more strange than the military being invlovled in specail
operations in Waco while the whole time the FBI lied to congress
about the use of and about the use of incedinary devices. What
congress and the publice don't know is that lying is an offical part
of doing business. It was what I hated most in my last several years
working for the governement. Keeping secrets is one thing. But plain
lying is something I think the government likes. The offical act of lying
actually causes great delay and confusion in the government becasue you get
in trouble if you tell the truth and it becomes confusing which people
your suppose to ly to. Of course with various branchs of the government
lying to each other why tell the truth to congress. I remmber missing
deadlines on projects at work because I could not get the needed info.
For the job. You go though offical channels and your told the information
is at washington we will get it next week. Of course weeks go to months
and that job is left aside. Then the shit hits the fan because the job was
not done then some high bearacrat bitches at you. You tell him to take a
flying fuck. He does some checking and sees you tried to get the info
but that since it wasn't called in by a MR X you didn't get it. You get the
ly and no one tells you that it was a lie. It is to fucking confusing becasue
even if you get a straight anwser about something there is a good chance
it is a ly. Of course Reno knew what happened in Waco she took full
responsibilty for the action. I heard her say so. Of course full
responsibility means that she doesn't give a shit and can do what she wants.
Just like the president. Know that I think about since the governemt only
rewards those corrupt enough to tell the best lies. We do have the
President our country desrives.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.misc,talk.politics.crypto
Subject: Re: Can americans export crypto when in another country?
Date: Fri, 27 Aug 1999 23:39:44 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] says...
>
>[ ... ]
>
>> I find it strange if not amusing that cryptographers from the US, civilian
>> and government, travel frequently to foreign locations where they share
>> their thoughts and ideas with other foreigners.
>
>Irrelevant -- sharing thoughts and ideas is (at least according to US
>law) an entirely different sort of thing from sharing software that
>takes specific actions. I.e. the difference is between sharing
>thoughts (falls under free speech) and giving you a machine that takes
>an action (no longer speech, and therefore not protected).
>
>If you read the reasoning in the recent court case, this specific
>point was emphasized: the defense for exporting source code was that
>the source code was being used primarily to communicate ideas to
>another person. As such, it was considered protected as free speech.
>Object code, which wouldn't normally be used for communication to
>another person, but would be used primarily for directing the actions
>of the computer, would (probably) no longer fall under the same
>protection.
>
>In short, writing, speaking, etc., about nearly any subject is pretty
>much free unless you sign some sort of agreement to the contrary ahead
>of time (e.g. an NDA or a release form when you receive a security
>clearance).
>
>Of course, in many cases, as with source code, it's difficult to
>separate the two -- in particular, if you describe an algorithm
>extremely explicitly and unambiguously, chances are pretty good that
>you'll end up using some sort of notation that _could_ be converted to
>a computer program by reasonably automated means; in many cases, the
>most obvious unambiguous language for describing many algorithms is a
>programming language.
>
>> Indeed, even the
>> government had one meeting of the AES in Rome last Spring, and I might
>> add, adjacent to a Fast Encryption Workshop.
>
>....which is perfectly fine as long as they didn't distribute machine-
>readable versions of the encryption algorithms to non-US citizens.
This is bogus they even have machines that convert speech to text.
And as technology gets better it will be easier and easier. IF it is speech
than it is the same as written.
It is difficult to separate the two only because a lawyer type wants it to
be. I am sure that if we ever get an honest court that the product of ones
on thoughts should some day be free.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: NEW THREAD on compression
Date: Sat, 28 Aug 1999 00:07:58 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>......................
>
>> Compression is just the opposite. Thanks for making me
>> take a longer look. I will post new code shortly. But if you
>> see an error in my logic let me now since it is I hope complete.
>
>I don't exclude that my current thinking is biased towards my own
>proposal and hence may be incorrect. But I conjecture that there
>could possibly be a situation that is difficult for your scheme to
>handle in a way quite analogous to the case of the file C consisting
>of 00000000 00000000 that has forced me to introduce the 'random
>feature' (admittedly rather artificial) in order to ensure
>consistency in ALL situations. I have not spend much thought about
>my conjecture but like to suggest that you take the following into
>consideration, since you are currently reviewing you program code
>anyway:
>
>Let there be defined:
>
> C1 = 11111111
> C2 = 11111111 11111111
> C3 = 11111111 11111111 11111111
>
>Could your program decompress these to D1, D2 and D3 and then
>compress back to C1, C2 and C3 without difficulties?
>
>M. K. Shen
if I rewrite this in hex it is easer for me
FF compressed to 00 and decompress FF
FF decompress to 00 and compresss to FF
FF FF compress to 00 80 and decompress to FF FF
FF FF decompressed to 00 00 .. ( 9 bytes of all zeros ) and compresses to
FF FF
FF FF FF compresses to 00 C0 and decompresses to FF FF FF
FF FF FF decompress to 00 .. ( 17 bytes all zero ) and compress back to
FF FF FF
so no problem but thanks for the test cases.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
