Cryptography-Digest Digest #979, Volume #11 Thu, 8 Jun 00 19:13:00 EDT
Contents:
Re: equation involving xor and mod 2^32 operations (Anton Stiglic)
Re: equation involving xor and mod 2^32 operations (Anton Stiglic)
Re: Question about recommended keysizes (768 bit RSA) ([EMAIL PROTECTED])
Multiple encryptions (AllanW)
Re: Question about recommended keysizes (768 bit RSA) ([EMAIL PROTECTED])
Re: Cryptographic voting ([EMAIL PROTECTED])
Re: RIP Bill 3rd Reading in Parliament TODAY 8th May (Chris Ward)
Re: Some dumb questions (Bryan Olson)
Re: Question about recommended keysizes (768 bit RSA) (DJohn37050)
Re: Some dumb questions (Jim Gillogly)
Re: Random IV Generation (tomstd)
Re: PGP Self-Decrypt (Tom McCune)
Re: 3DES performance (Svend Olaf Mikkelsen)
Re: Thoughts on an encryption protocol? (Bryan Olson)
Re: Some dumb questions (Jim Gillogly)
----------------------------------------------------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: equation involving xor and mod 2^32 operations
Date: Thu, 08 Jun 2000 17:14:13 -0400
Thanks for all the useful replies!
Anton
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: equation involving xor and mod 2^32 operations
Date: Thu, 08 Jun 2000 17:17:51 -0400
Clive Tooth wrote:
>
>
> Interesting.
>
> Let a, b and x be n-bit numbers and let + be the add mod 2^n operator.
> Fix a and b. Let x range through all n-bit numbers.
> It appears that the maximum number of distinct values that (a+x)xor(b+x) can
> assume (depending on the choice of a and b) is F_(n+1), the (n+1)'th
> Fibonacci number.
>
> I have no proof of this.
Interesting, how did you derive this conjecture?
Anton
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Thu, 08 Jun 2000 21:07:35 GMT
In article <8hjdrg$bc5$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <8hiv0a$v21$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> > > You want a "high-end" machine in 1977? Try the CDC-6600.
> >
> > Bob, I hate to point it out, but your knowledge of the history of
> > computing seems badly defective.
>
> ROTFL.....
>
> I was *there*. I was working at DEC when the VAX was first introduced
> and was coding on high end CDC machines in 1978. (doing linear
> programming). I was even coding on the CRAY-1S in 1980.
>
> The VAX was considered a 32-bit MINI-Computer, even by DEC when it
> was introduced. It was anything but a high end machine.
The VAX was a very good number cruncher but really poor performance as a
multi-user system..terminal IO was terrible....The baby VAX ( 750 ) and
its bigger brother 780 and the Micro VAx were all scientific
machines...however, by running a VAX cluster, you could outperform most
mainfames of those days including the CDC 6600...which was primarily a
batch machine...
> --
> 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/
> Before you buy.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Multiple encryptions
Date: Thu, 08 Jun 2000 21:08:12 GMT
We have some encryption program E, and we use it whenever
we send messages to each other. E is meant to take any
plaintext (even non-printable data) and encrypt it, to
transmit it safely to other sites. E identifies the
encrypted data with a brief cleartext message at the
start of it's output, to allow the decryption engine to
avoid trying to decrypt data that never was encrypted.
Therefore, anyone that can intercept our messages already
knows we use encryption program E.
Secretly, we also have another encryption program D. It
isn't public knowledge, but what we really do is take our
data files and encrypt them with D. Then we take the D
output and feed that into E. Programs D and E know
nothing of each other; each is meant to be used as a
stand-alone encryption engine. D also appends some
cleartext at the beginning of it's output, but of course
E encrypts that so our use of D is *mostly* a secret.
I've heard that this hypothetical case is a bad idea, and
not just because of any false sense of security. Someone I
respect tells me that the result is actually LESS secure
than using either D or E alone.
How can this be?
Let's say that word leaks out that we're using D before we
use E. Someone uses this knowledge to come up with
frequency distribution or some other pattern for D's
output. Perhaps it gives them a minor leg up on what output
to expect from E. But can the result actually be easier to
crack than cracking D or E alone?
If you can explain why the answer is YES, then I have
another related question:
Suppose that D is a home-grown "security by obscurity"
encryption engine that was never released to the public.
Therefore it was never given public scrutiny, and it may in
fact have one or more extreme weaknesses that anyone
familiar with encryption (except the author) could have
easily detect, if they got a chance to review the code
and/or analyze the output. But, the source code is held by
a few trusted individuals and the "encrypted" output is
never retained after it's been fed to program E or returned
out of program E, so there's no way to do frequency analysis
or anything similar. Does your explanation to the first case
still fit the second case?
Obviously these cases are all hypothetical and I'm not
advocating anyone actually doing this. I appreciate any
explanations you can give me.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.privacy.anon-server,alt.security.pgp
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: Thu, 08 Jun 2000 21:13:43 GMT
I am curious as to why people think that 1024 bits RSA is not
vulnerable... according to Stahling's book....p 181.. 1000 bit integer
can be factored with 10**7 MIP-Year. Current Cray T3's run at over one
terraflops...well thats pretty near factoring a 1000 bit key...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: Cryptographic voting
Date: Thu, 08 Jun 2000 21:14:00 GMT
Unfortunatly, I am having trouble understanding what you are talking
about.. your sentences are quite jumbled. That said, it is quite
possible I am not understanding what you are saying, but I think in some
cases you are incorrect. Specific comments in the text.
(BTW, when looking for information on "meranda" you will do better to
search for "Miranda".)
In article <8hov6o$gu4$[EMAIL PROTECTED]>,
Greg <[EMAIL PROTECTED]> wrote:
> And I wonder how many people refuse to vote because of this. Did you
> know that NV state legislature was composed of many patriotic men and
> women who passed a bill (though I do not know if it actually became
> law) to mint their own coins? They were going to mint their own
Nevada
> silver dollars with real silver and fling it in the face of the US
> government. Their position was, "Unless and until you abide by the US
> constitution to coin money exclusively, neither shall we abide by the
> same." In other words, they were saying that the US must not allow
the
> FED to coin money or they would coin money also. And since their
coins
> used real sivler there would be a true dual economy competing for
> Americans to operate under. And since the FED note is no longer based
> on precious anything but are merely debt, NV coins looked real good.
I don't understand your sentence about the constitution. I don't think
the constitution of the US mentions legal tender in any form (although
it has been a while since I have read it). Had Nevada decided to mint
their own money, it would be a continuation of an old practice. Even as
recently as roughly 1900 banks were issuing their own notes. I am not
sure when people got tired of talking to a bank away from their home
state to get their gold, but I think nearly everyone living in the US
will agree a common united states currency is a Good Thing.
However, you can mint your own currency, and no one will stop you. If
they choose to honor it, of course, it up to them. Many societies around
the country are based on the ideas of a new currency, one based on hours
of work in an effort to be more fair than one based on a fixed amount of
serial numbers in circulation.
The decision to move off the gold standard was a difficult one to make,
but those in charge at the time did it to prevent the united states from
being screwed when other countries were asking for *lots* of gold. Our
economy could have been destroyed. Of course, we don't know what would
have happened, but the results certainly don't seem too bad currently.
> Did you know JFK was assassinated three weeks after signing an EO that
> would force the federal government to coin money apart from the FED?
> Coincidence? I don't believe so.
And I bet he went to the bathroom the day before he was assassinated.
Coincidence? I don't believe so.
> JFK was the first and only president that stood up to the NWO (calling
> Kissinger a mad man that was never permitted to enter the white house
> grounds) and tried to take back our government from the powerful
forces
> that ultimately took him from us. And they feared his brother Robert,
> but they seem to like Teddy (perhaps he was corrupted too much to
stand
> in the light of day?).
>From what I have read of Kissinger, wasn't he a Harvard professor at the
time? He did some consulting on global issues, and was interested in
getting Rockefeller into the White House, but I don't think he
interacted with JFK much, *if at all*. I could be wrong. Although, if
Kissinger was involved with the NWO, wouldn't that have been much later
in his life? (For that matter, I can't find out when the NWO was
*started*. Searching for this information is painful, since most
webpages with "NWO" in their names refer to wrestling.)
This thread should be moved to alt.conspiracy. Please follow up there
unless you can tie your responses into cryptography or mathematics.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Chris Ward <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RIP Bill 3rd Reading in Parliament TODAY 8th May
Crossposted-To: uk.media.newspapers,uk.legal,alt.security.pgp
Date: Thu, 8 Jun 2000 22:14:22 +0000
=====BEGIN PGP SIGNED MESSAGE=====
On Wed, 07 Jun 2000, zapzing wrote:
>
>Since the isomorphism is not a "key" in any
>way that would probably not be covered by
>the law so you would not be required to
>give it.
>
What most people seem to be overlooking is that the first "request" will be for
you to provide the plaintext of what "they" consider to be encrypted
information. At this point keys don't come into consideration. You may have
stuff that is conventionally encrypted on your PC or floppy or whatever.
There's no "key" in the sense being discussed here. Just a passphrase that's
impossibly difficult to crack. Which is why the first requirement will be for
you to decrypt the information for them. If you can't they will assume that
it's because you won't. And you're now going to be charged with a criminal
offence (not providing the plaintext) and the court will assume you are guilty.
Proving that you're not is going to be extremely difficult - probably
impossible - and muttering on about no longer having the decryption key will
only make matters worse
Of course "they" can then confiscate everything in sight in the hope of
discovering an appropriate key, and a passphrase to go with it. But you're
already in chokey.
Chris Ward.
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQCVAwUBOUAfi8oHR8g+vP61AQF1fgP9FgdBtpj+opRq2qkAlmmWmEXq3Nw/eiRW
l9QACshiSTk5xjvME5n/VbZRIXTUaP2SOKkpn2qz5bmZ/S1wTjh6rfnz0EJ45s/B
r5SumUg70VpRO9VZve48ZMELUgSPokMexXXE7bb98wjwlDjKwH0SiiGILCrm+/Qj
H8F/neVjZV8=
=+CPQ
=====END PGP SIGNATURE=====
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Thu, 08 Jun 2000 21:33:52 GMT
Mok-Kong Shen wrote:
> This confirms the
> appropriateness of the restriction in my assumptions (see follow-ups
> later than the first post in the thread) that n-gram frequency
> distributions are not exploitable by the opponent (to be rendered
> flat through appropriate measures).
The first tricky part of an empirical study is to form the
question so that it's focused enough to have a good chance
of getting a result, without being so much a "special case"
that it's irrelevant. There's a huge range of things one
could add to a two-time pad to flatten frequency
distributions, so you'd have to consider whether any stand
out as most interesting.
I agree with Jim Gillogly's comments, and I think there's a
danger that people will take the wrong lesson from some
practical results. One might think that a lesson from
Venoma is that the steps added to the OTP should have been
made stronger. My opinion is the opposite - whatever effort
was devoted to these additional measures should instead have
been directed to using the pad properly.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Question about recommended keysizes (768 bit RSA)
Date: 08 Jun 2000 21:54:18 GMT
See www.cryptosavvy.com for an estimate based on TIME (ops) that says that one
should not use 1024 bit RSA past 2002. Also, I hear German sig. law says
something similar.
Don Johnson
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Thu, 08 Jun 2000 21:56:00 +0000
Mok-Kong Shen wrote:
> you can break it, then you have identified that the originals belong the
> same segment of OTP. Is that right? (But then you have succeded
> in fact to read the messages.) Now could you give some sketch of
> ideas that underly such a program? (Please note my assumption
> that you have the frequency distribution of single characters, but
> nothing else. You have the xor of a pair. But from the start you have
> no idea at all of whether they belong to the same pair. If they don't,
> then you have the xor of two messages xored with two OTP segments.
> Note now that xor of two OTP segments can be 'anything', according
> to the definition of OTP.) Could you give some tiny hypothetical but
> concrete examples to clearly illustrate (roughly) these ideas?
> (It was implicitly my point that the invention of these ideas are very
> hard.) Thanks in advance.
It seems to me that you're not clear on how one determines that two
messages have been encrypted with overlapping pads, and how to determine
the amount of overlap. To do this, use a kappa test: slide the two
ciphertexts against each other and count the number of coincidences
at each offset -- i.e. the number of times characters match in the
two strings. It's very fast and effective, and uses only single
characters at each point. With a respectable-sized overlap of the
random keypad, you get a strong peak in the counts.
I suggest you try a few actual experiments with random numbers
and English text to see how easy and effective it is.
--
Jim Gillogly
19 Forelithe S.R. 2000, 21:48
12.19.7.4.19, 12 Cauac 2 Zotz, Ninth Lord of Night
------------------------------
Subject: Re: Random IV Generation
From: tomstd <[EMAIL PROTECTED]>
Date: Thu, 08 Jun 2000 15:06:17 -0700
In article <8houts$gpq$[EMAIL PROTECTED]>, sarnold_intertrust@my-
deja.com wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Charles) wrote:
>> I'm currently puzzling over how to generate an IV to get a
Blowfish in
>> CBC started. I need 64 random bits, but I'm unsure how to
actually
>> collate them. The following options immediately come to mind:
>
>What you could do is hash the current time of day with md5 and
xor the
>uppermost 64 bits with the lowermost 64 bits. That will sort-of
evenly
>spread the bits around. While it subtracts from the entropy of
just
>using the time of day all by itself, it at least makes the bits
depend
>upon each other fairly well. (whereas using the time of day
causes all
>IVs used to start with "96" for the next 110 days, 97 for 111
(or so)
>days, etc..)
>
>Whether that helps the strength, I dunno.
>
>And, if you do decide to use sha1, I think truncating ought to
work too,
>I have seen that used in more than a few places.
Please define the "Strength" of a IV.
Tom
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tom McCune <[EMAIL PROTECTED]>
Subject: Re: PGP Self-Decrypt
Date: Thu, 08 Jun 2000 22:27:42 GMT
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In article <8hovgh$h9e$[EMAIL PROTECTED]>, AllanW <[EMAIL PROTECTED]>
wrote:
>I've heard that new versions of PGP have a "self-decrypt" mode
>that lets you send encrypted data to someone without PGP. But
>how does this work?
>
>If the recipient doesn't need PGP, then this can't support
>public-key encryption, right? Does it ask for a password?
>
>If it uses a password to decrypt, isn't it vulnerable to
>brute-force attacks?
>
>If it doesn't even need a password, doesn't that mean
>that it can be "decrypted" by anybody that receives it?
It does require a passphrase - it is conventional encryption.
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.5.1
Comment: My PGP Page & FAQ: http://www.McCune.cc/PGP.htm
iQA/AwUBOUAd6A2jfaGYDC35EQIlGgCeLF/K+n3ArOKv4eiPIEGy1DbQ4aUAoNaH
kFWZL3DZ9mDtg906e6ZRoewv
=i4JD
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Svend Olaf Mikkelsen)
Subject: Re: 3DES performance
Date: Thu, 08 Jun 2000 22:36:21 GMT
Eric Young <[EMAIL PROTECTED]> wrote:
>H�m�l�inen Panu wrote:
>> Can someone tell me where I could find some
>> performance measurements/comparisons of Triple-DES
>> or DES (software) on different technologies? So far
>> I have only found results on Pentium by
>> Antoon Bosselaers.
>
>Some old numbers I have for software, all for Triple DES
>in CBC mode. What is interesting is the difference between
>the two MIPS CPUs at the same clock speed.
>(k/sec == 1000s of bytes per second)
>
>1990k/sec Alpha EV5.6 (21164A) 400mhz (Jun-1997) (C code)
> 161k/sec 486 66mhz (Jul-1996) (C code)
> 741k/sec Pentium 100 (Sep-1997) (ASM code)
>1570k/sec Pentium Pro 200 (May-1997) (ASM code)
>1340k/sec MIPS R10000 195mhz (Dec-1996) (C code)
> 657k/sec MIPS R4400 200mhz (Dec-1996) (C code)
>
>2890k/sec Pentium II 350mhz (Jun-2000) (ASM code)
> 710k/sec StrongARM 275mhz (Jun-2000) (C code)
1763k/sec Sun UltraSPARC 168mhz (Jun-2000) (ASM code)
--
Svend Olaf
http://inet.uni2.dk/~svolaf/des.htm
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Thoughts on an encryption protocol?
Date: Thu, 08 Jun 2000 22:30:31 GMT
Dido Sevilla wrote:
> John Myre wrote:
> >
> > First, the technique of creating the session key based on
> > the prior key seems prone to problems. Not security problems,
> > but communication problems. If you ever lose "sync", you need
> > to design a way to recover. You need to consider lost messages,
> > reboots (on either end), and so forth.
> >
>
> I have been thinking about the resynchronization problem a lot
> actually. Sometimes, I'm actually tempted to completely abandon that
> system and make use of a noisy semiconductor diode in my client
> terminals, hash the results from reading its random noise to generate
a
> key, and transmit the new key using a long-term secret, rather than
> performing all this synchronous fiddling. Use one key for all
> transactions in one day only, so that the long-term secret need not be
> reprogrammed too much...
Then if anyone does crack the client, the break can reach
backward to expose every message sent while the long-term
secret was in use. The roll-forward of the keys was a good
idea; by deleting the old keys, you obtain what
cryptographers call "ephemeral keys" or "forward secrecy".
You might want to keep a master key and derive session keys
from it, but a solution that loses forward secrecy would be
a step in a wrong direction.
So let's outline a solution to the synchronization problem.
It does not require exactly-once semantics, or even a
sliding window of keys. Each side starts with the same key,
and keeps a counter that increments on each roll-forward.
Each message includes the current counter. If one side gets
a message with a count higher than his own current counter
value, he can roll-forward to the given counter and key.
If one side receives a message with a lower count, he has to
send back a message telling what his current value is, so
the remote end can roll the key forward and re-send. If
re-send logic is too expensive, let the client initiate all
the forward rolls, so the server does them only in response
to client messages. As long as the client speaks first, no
re-transmits are required.
If you're concerned with denial of service attacks, you can
bound the number forward-rolls each side will do in response
to a single message, and only delete the old key value when
the message verifies under the new key.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Some dumb questions
Date: Thu, 08 Jun 2000 22:46:43 +0000
William Rowden wrote:
>
> In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> > Going back to the original question (informed by a later message that
> > assumes the underlying frequencies of the plaintext are known), I did
> > a little example. I took the first n=10 sentences of Pride and Prejudice
> > that are at least 15 characters long, and pulled out the 15th character
> > of each,
>
> This creates a sample from an English distribution, without any
> English n-grams. Is that your intent?
Yes -- that was M-K Shen's, intent, which I was honoring for the experiment.
> > then XORed those characters with a randomly selected key.
>
> The randomly selected key was 10 characters (or 80 bits) long?
No, it was 8 bits long, representing a single character of 10
messages encrypted with an overlap discovered in a 10-time-pad.
> > The ciphertext is: 0f 5a 1f 16 1f 1f 14 5a 1b 5a
> >
> > Now look at all possible values of the key.
>
> This is a brute force solution. Doesn't each additional character in
> the message increase your keyspace by 2**8 (or 2**6 if you limit keys
> to letters, numbers, and some punctuation)? I predict computational
> infeasibility.
Not by my definition of brute force. Each character position is
recovered separately, so recovering the whole key is linear in the
length of the full 10TP key. Bear in mind that each character position
represents a vertical slice of depth 10 through the aligned stack
of 10-time-pad messages. As a definitional matter unrelated to the
demonstration at hand, if you eliminate whole sections of a search
with some criterion (e.g. "none of these potential keys would produce
an ASCII value in this position") you have moved beyond brute force.
> It seems to me that the XOR of two ciphertexts encrypted with the same
> random key is equivalent to transposed plaintext encrypted with a
> cryptographically weak pseudorandom number generator.
I don't see why it seems like that to you. I think we are looking
at different problems. The problem I was addressing was how many
overlapped messages you might be able to get away with in order to
have a good idea of the pad value at one position with no other
information available from n-graphs around it. My tentative
conclusion is that with even just a few of them (certainly fewer than
10) you could get enough accuracy to solve an underlying simple
transposition with little effort.
--
Jim Gillogly
19 Forelithe S.R. 2000, 22:32
12.19.7.4.19, 12 Cauac 2 Zotz, Ninth Lord of Night
------------------------------
** 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
******************************
