Cryptography-Digest Digest #186
Cryptography-Digest Digest #186, Volume #14 Thu, 19 Apr 01 19:13:01 EDT Contents: Re: UNCOBER = Universal Code Breaker (John Savard) Re: Reusing A One Time Pad (Paul Pires) Re: OTP breaking strategy (newbie) Re: Current best complexity for factoring? (Tom St Denis) Re: OTP breaking strategy (Tom St Denis) Re: OTP breaking strategy (SCOTT19U.ZIP_GUY) Re: OTP breaking strategy (newbie) Let's end this OTP argument (Tom St Denis) Re: OTP breaking strategy (Joseph Ashwood) Re: Thanks for all replies reg:passphrase salting (Joseph Ashwood) Rijndael/AES VB Code (Phil Fresle) Re: UNCOBER = Universal Code Breaker (newbie) Re: UNCOBER = Universal Code Breaker (Tom St Denis) Re: OTP breaking strategy (newbie) Re: Crypto question (Robert M Best) Re: OTP breaking strategy (newbie) Re: Crypto question (Shaft) Re: Crypto question (Ivo Brugman) From: [EMAIL PROTECTED] (John Savard) Subject: Re: UNCOBER = Universal Code Breaker Date: Thu, 19 Apr 2001 22:03:52 GMT On Thu, 19 Apr 2001 14:38:17 -0300, newbie [EMAIL PROTECTED] wrote, in part: If the message is 100101010 and the ouput 11 you are quite sure to reject the possible key. The fraction of possible keys that are statistically nonrandom is nearly infinitesimal, and so this is unlikely to eliminate any possible plaintexts. Furthermore, it is generally considered an error when doing an OTP to reject random keys because they don't look random, although using a pad consisting of 000... to encrypt a message would make all but the stoutest hearts quail. (We had an interesting debate on this issue some time ago.) John Savard http://home.ecn.ab.ca/~jsavard/crypto.htm -- From: Paul Pires [EMAIL PROTECTED] Subject: Re: Reusing A One Time Pad Date: Thu, 19 Apr 2001 15:00:33 -0700 And Freud was a mother fu*king as*hole that spawned a small universe of devils, like you perhaps. But that's as bit off topic so I will refrain from commenting any further. Perhaps in a psych group. *PLONK* I find your comments rude, agumentative, childish, biggoted and irresponsible. Luckily, there is a way not to find you at all any more. -- From: newbie [EMAIL PROTECTED] Subject: Re: OTP breaking strategy Date: Thu, 19 Apr 2001 17:58:35 -0300 You are reaching what I had tried to prouve. You could distinguish with extra-information which message is valid. And select the message. Because, the plaintext is deterministic sequence. If you could distinguish truly random output and not random, you have still a way to break it. I know it is very hard. Very very hard. It is like rebuilding the plaintext with very few information. I said OTP could be broken practically. In theory, I KNOW that is unbreakable, but If you combine the context factor and other extra-information you can break it. [EMAIL PROTECTED] wrote: newbie [EMAIL PROTECTED] wrote: : When you introduce the context factor all the messages are not : equiprobable. : That is the way to try to find out the input. : If I analyse any output of 128 bits I will obtain 2^128 messages. I know : that. : But all the messages are not 100% in the context. : And all the output are not 100% random. : I have two ways to select : context factor and degree of randomness. Okay, remember that you don't have access to the pad itself. Now, suppose I have two different pads and I encrypt the following two messages: SELL 750 SHARES BUY 1000 SHARES Since I am not reusing the OTP, I encode each message with a different pad. By some bizarre coincidence, the pads happen to encrypt their messages to exactly the same result: 5e8f128c65a30954371a7e494217ad Now, given that the two messages are reasonably within the same context here, how can you possibly tell which one I actually sent? You might be able to guess which one I sent by analyzing my business and maybe by planting spies in my office, but at that point, you haven't really broken the OTP. In fact, you might figure out that I need to send the BUY 1000 SHARES message, but because I made a mistake, I sent the SELL 750 SHARES message. -- Mark Wutka -- From: Tom St Denis [EMAIL PROTECTED] Subject: Re: Current best complexity for factoring? Date: Thu, 19 Apr 2001 22:07:45 GMT SCOTT19U.ZIP_GUY [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... [EMAIL PROTECTED] (Terry Boon) wrote in [EMAIL PROTECTED]: Given this unless someone finds a factoring algorithm that is easier when the primes come after a long stream of composites, there is no additional risk. This is what I suspect. I would find it curious and surprising to find a factoring algorithm that had this property. You can bet the NSA has devoted a great deal of research into taking advantage of this flaw in the way primes are picked. But I don't think
Cryptography-Digest Digest #186
Cryptography-Digest Digest #186, Volume #13 Sun, 19 Nov 00 09:13:01 EST
Contents:
Re: Criteria for Simple Substitutions? (John Savard)
Re: XOR: A Very useful and important utility to have (proton)
Re: Cryptogram Newsletter is off the wall? ("Brian Gladman")
Re: A Question About Multi-encrypting ("Scott Fluhrer")
Re: Mode of operation to maintain input size with block ciphers? (Paul Crowley)
Re: Mode of operation to maintain input size with block ciphers? ("Benny Nissen")
Re: Cryptogram Newsletter is off the wall? (Simon Johnson)
Re: A Question About Multi-encrypting (Simon Johnson)
Re: Cryptogram Newsletter is off the wall? ([EMAIL PROTECTED])
Re: Big-block cipher, perhaps a new cipher family? (Mok-Kong Shen)
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Criteria for Simple Substitutions?
Date: Sun, 19 Nov 2000 11:34:38 GMT
On Sun, 19 Nov 2000 10:26:08 GMT, "news.free.fr"
[EMAIL PROTECTED] wrote, in part:
An interesting question
How can we measure the "strength" of a permutation ?
Is there some references in books or web site ?
Well, the S-boxes in DES were supposed to be strong; nonlinearity is
required, and there is material on 'bent functions'.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: proton [EMAIL PROTECTED]
Subject: Re: XOR: A Very useful and important utility to have
Date: Sun, 19 Nov 2000 11:56:33 GMT
Guy Macon wrote:
Anthony Stephen Szopa wrote:
XOR: A Very useful and important utility to have
A few people in this news group said any XOR program is less than
useless.
Balderdash. What people have said is that *YOUR*
XOR program is less than useless. Which it is.
Maybe mine can be a little bit more useful? =)
[1] It's 156KB zipped. Bloatware Alert! Bloatware Alert!
Mine's ~4K in Linux (after stripping it).
[2] You haven't published the source code. Security Risk! Security Risk!
I publish only the source :]
I just wrote this for fun. And im posting it for fun.
Just to prove that not everyone is out to rob your wallet
for some tiny tool that you could easily write yourself.
Yes I know he says its freeware, but Im pretty sure that
somewhere in there is a nag screen or such that will annoy
you to no end. Thats not useful in my book.
Anyways, your copy of `the extra small but maybe useful XOR utility'
can be picked up at http://www.energymech.net/users/proton/ .
GPL source, naturally. I hope /someone/ likes it :)
/proton
--
From: "Brian Gladman" [EMAIL PROTECTED]
Subject: Re: Cryptogram Newsletter is off the wall?
Date: Sun, 19 Nov 2000 12:09:35 -
"Tom St Denis" [EMAIL PROTECTED] wrote in message
news:8v6rvq$429$[EMAIL PROTECTED]...
In article [EMAIL PROTECTED],
Bruce Schneier [EMAIL PROTECTED] wrote:
On Sat, 18 Nov 2000 14:28:18 GMT, Tom St Denis [EMAIL PROTECTED]
wrote:
About the signatures. Perhaps Mr Schneier forgot that private keys
are
often password protected. Unless "Alice" has a poor or easy to guess
password it's not so easy to use her signature without her knowing.
And like real signatures I could forge it anyways without her
knowing.
We've reached the point where passwords do not provide security
against off-line attacks.
There is an upper limit of what people can be reasonably expected to
remember and type in. And over the years, the efficacy of dictionary
attacks has increased. A few years ago, the two crossed.
Look at programs like L0phtCrack.
In any case, passwords are besides the point. If I have a Trojan on
your computer, I can easily wait until you type your password and
decrypt your private key...and then steal it.
Yeah, but there are analogies for any of your counterpoints into the
real world. Look at a trojan. I could review tape of a bank when you
sign a cheque. I could then study your signing patterns (the way you
make your letters) and forge your signatures.
Like a trojan horse proximity is a problem. Albeit sometimes it may be
easier to install trojans on foolish users (or anyone using outlook)
but still for the most part the attack is remote.
This is an underestimate of the problem of trojans. It is quite difficult to
guard against this and quite wrong to imply that only foolish users are
vulnerable.
A covert virus designed to silently look for, capture and report bank
account access codes has already been seen in action.
I think when a digital signature is done properly it can be just as
semantically secure as a real signature.
But it is not possible to do a digital signature 'properly' with the
hardware and software that most people now use.
As Bruce says there is a huge difference between a person signing something
and a computer doing this. These are not even remotely similar activities.
Cryptography-Digest Digest #186
Cryptography-Digest Digest #186, Volume #12 Sun, 9 Jul 00 18:13:00 EDT
Contents:
Re: Efficient algorithm to determine relative primality? (Bryan Olson)
Re: Proposal of some processor instructions for cryptographical (Terje Mathisen)
Re: Using CRC's to pre-process keys (David A. Wagner)
Re: Advanced Cryptography FAQ (James Pate Williams, Jr.)
Re: Proposal of some processor instructions for cryptographical(Mok-Kong Shen)
Re: Proposal of some processor instructions for cryptographical (Iain McClatchie)
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
Re: Proposal of some processor instructions for cryptographical(Helger Lipmaa)
Re: Proposal of some processor instructions for cryptographical (Mok-Kong Shen)
CP algorithm ("Theophilus Samuels")
Re: Advanced Cryptography FAQ (John Savard)
Re: Proposal of some processor instructions for cryptographical applications (John
Savard)
From: Bryan Olson [EMAIL PROTECTED]
Subject: Re: Efficient algorithm to determine relative primality?
Date: Sun, 09 Jul 2000 19:58:55 GMT
ChenNelson wrote:
Would someone know an efficient algorithm for determining whether
numbers x and y are relatively prime, without havng to necessarily
calculate gcd(x,y) using Euclid's method? Calculating the gcd of two
numbers using Euclid's method is too slow for crypto-size (100+digits)
numbers. Thanks.
I don't think any significantly faster algorithm is known.
Euclid's algorithm* is blazingly fast. The usual
implementation is quadratic in the number of digits,
and much faster than exponentiation.
(*) I assume we're talking about the modern version of
Euclid's algorithm, based on
for x != 0, GCD(x, y) = GCD(x, y mod x).
As I understand things, the ancient Greek version
reduced the problem using
GCD(x, y) = GCD(x, y-x)
which would be slow.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Terje Mathisen [EMAIL PROTECTED]
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical
Date: Sun, 09 Jul 2000 17:36:25 +0200
Mok-Kong Shen wrote:
Terje Mathisen wrote:
Since future crypto algorithms will work with a minimum block size of
128 bits, this instruction would at the very minimum be capable of
working with half that size, i.e. 64-bit registers. A generalized
bit-shuffle operation would then need something like 64 * 6 = 384 bits
of shuffle index data. (This could theoretically be limited to the
number of bits needed to encode 64!, but I would not like to try to
dynamically split this at runtime. :-()
I think that 64-bit PCs are in the coming, and the price of 64-bit
workstations are going down to be affordable to those having serious
encryption jobs that justify higher expenses. For a 128-bit algorithm,
64-bit permutation is not too bad, I suppose, noting that for a Feistel
cipher one splits the block into two halves. Could you please explain
why you need 384-bit permutations for a 128-bit algorithm? Thanks.
Please re-read my post above: If each output bit can come from any of
the 64 possible input locations, then it will need a 6-bit number
(0..63) to specify that relationship.
Doing the same for all 64 input/output bits would then require 6*64 =
384 index/routing bits.
So, do you want something like a fixed 6-register block, where the first
register to be used is specified as part of the instruction, or do you
want to have a 384-bit immediate operand to the opcode?
Terje
--
- [EMAIL PROTECTED]
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
--
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Using CRC's to pre-process keys
Date: 9 Jul 2000 13:13:02 -0700
In article [EMAIL PROTECTED],
Mack [EMAIL PROTECTED] wrote:
If the 160-bit hash is reduced to 128 bits (again pick your method of
reducing it) collicions occur after 2^64 inputs. When you reduce your
key to produce 128 bit output the birthday paradox applies to the
reduced value not the original value.
Yes, quite right.
What's not clear is why this is at all relevant to the application of
hashing entropy sources to get key material. I don't know about you,
but the number of keys _I_ have ever generated falls far short of 2^80...
Since the original post was about ASCII text key processing I am
not sure it is.
Er... huh? Sorry, I don't know how to read your comment. Are you
suggesting that you might want to generate more than 2^64 keys in your
life?
--
From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: Advanced Cryptography FAQ
Date: Sun,
Cryptography-Digest Digest #186
Cryptography-Digest Digest #186, Volume #11 Wed, 23 Feb 00 11:13:01 EST
Contents:
Re: Large Int Lib for Delphi ("ink")
Re: Q: Large interger package for VB? (longreply with source) ("Neila Nessa")
Re: Does the NSA have ALL Possible PGP keys? ("csabine")
Re: Does the NSA have ALL Possible PGP keys? ("csabine")
Re: Passwords secure against dictionary attacks? (Ilya)
Re: US secret agents work at Microsoft claims French intelligence report (Gordon
Walker)
Re: Transmitting ciphered data (Volker Hetzer)
Re: Implementation of Crypto on DSP ([EMAIL PROTECTED])
DES algorithm (Charles Nicol)
Re: RSA Speed ([EMAIL PROTECTED])
Re: need help! decryption (wtshaw)
Re: need help! decryption (wtshaw)
Re: DES algorithm (Jean-Jacques Quisquater)
Re: shorter key public algo? (JCA)
Re: need help! decryption (Richard Herring)
From: "ink" [EMAIL PROTECTED]
Subject: Re: Large Int Lib for Delphi
Date: Wed, 23 Feb 2000 14:37:22 +0100
Thank you very much!
Ryan Phillips schrieb in Nachricht [EMAIL PROTECTED]...
check www.scramdisk.clara.net and click delphi.
Ryan
ink wrote:
Does anyone know of a large integer library for
Borland/Inprise Delphi, Version 3 or higher? A
Turbo Pascal ;-) version would also be welcome,
as the language/compiler is essentially the same.
Thanks a lot in advance, kind regards
Kurt
--
From: "Neila Nessa" [EMAIL PROTECTED]
Subject: Re: Q: Large interger package for VB? (longreply with source)
Date: Wed, 23 Feb 2000 07:44:47 -0600
Crossposted-To: comp.lang.basic.visual.misc,comp.lang.basic.visual.3rdparty,sci.math
This isn't what you are looking for either, but I found it to be an amusing
site ;-)
http://www.jargon.net/jargonfile/b/bignum.html
Neila
Ed Pugh [EMAIL PROTECTED] wrote in message
news:88v4cn$hrj$[EMAIL PROTECTED]...
Thanks for your follow-up, Michael, but I do not think this is quite
what I am looking for.
It appears that the module you posted does arithmetic on large
precision decimal numbers, NOT integers (or natural numbers).
Also, it did not appear to implement the modulus operation,
which I need.
As well, I noticed that it seemed to have a "naive" implementation
of the exponentiation function which, for the sizes of exponents
I am talking about, would probably take a few millenia to execute!
Does anyone know of any better VB implementations of large integer
packages?
Michael Carton ([EMAIL PROTECTED]) wrote:
I trimmed the NG list.
Why? I added them back!
Ed Pugh wrote:
I want to use Visual BASIC (5.0, pro ed'n, SP3) to do some
prototyping and experimenting with algorithms involving very
large natural numbers or integers.
Does anyone know if and where I can find and download a
*FREEWARE* (or *UNCRIPPLED* shareware) VB class or "library"
that can handle arbitrarily large natural numbers or integers
(up to a few thousand bits long)? (And it has to work with
VB 5.0.)
Here's something I downloaded. Free Source. I tested it with numbers
with up to 2,090 digits. It works.
Bet you did not try a number this size as an exponent (i.e. 2nd
parameter) for the IntPower function! ;-)
[ SNIP - VB module source code ]
Thanks and regards,
--
Ed Pugh, [EMAIL PROTECTED]
Richmond, ON, Canada (near Ottawa)
"Bum gall unwaith-hynny oedd, llefain pan ym ganed."
(I was wise once, when I was born I cried - Welsh proverb)
--
From: "csabine" [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Wed, 23 Feb 2000 13:43:48 -
Kinda reminds of what Descartes once said:
Of all things, good sense is the most fairly distributed: everyone thinks he
is so well supplied with it that even those who are the hardest to satisfy
in every other respect never desire more of it than they already have.
Discours de la Méthode. 1637.
Colin.
B Poulton wrote in message ...
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Steve K) wrote:
I just read most of this thread, and it's a very silly thread.
Agreed. I've been following it because I know little about it. Yet. In
conjunction with the original post I don't think this article is off topic.
(Note: This is *not* a slam against Americans. It's just that the study
groups were primarily American).
Incompetent people rarely know they are
By Deborah Zabarenko
WASHINGTON, Jan 20 (Reuters) - The truly incompetent may never know the
depths of their own incompetence, a pair of social psychologists said on
Thursday.
"We found again and again that people who perform poorly relative to
their peers tended to think that they did rather well," Justin Kruger,
co-author of a study on the subje
Cryptography-Digest Digest #186
Cryptography-Digest Digest #186, Volume #10 Mon, 6 Sep 99 02:13:04 EDT
Contents:
Re: Quantum computing bit in UK computing magazine.
Re: THE NSAKEY (SCOTT19U.ZIP_GUY)
Re: IDEA- safe? (Johnny Bravo)
Re: RSA the company ("Roger Schlafly")
Re: point of a cipher (SCOTT19U.ZIP_GUY)
Re: One to One Compression updated (SCOTT19U.ZIP_GUY)
Re: point of a cipher (SCOTT19U.ZIP_GUY)
Re: point of a cipher (SCOTT19U.ZIP_GUY)
Re: IDEA- safe? ("Trevor Jackson, III")
Re: Can we have randomness in the physical world of "Cause and Effect" ? (Dave Knapp)
Re: arguement against randomness ("Douglas A. Gwyn")
Re: Description of SQ ("Douglas A. Gwyn")
Re: arguement against randomness ("Trevor Jackson, III")
Re: point of a cipher ("Trevor Jackson, III")
Re: Quantum computing bit in UK computing magazine. ("Trevor Jackson, III")
Re: NSA and MS windows ("Douglas A. Gwyn")
Re: Mystery inc. ("Douglas A. Gwyn")
From: [EMAIL PROTECTED] ()
Subject: Re: Quantum computing bit in UK computing magazine.
Date: 6 Sep 99 02:17:32 GMT
Bill Unruh ([EMAIL PROTECTED]) wrote:
: They perform a computation on
: a single input state which, if viewed in a certain way, can be regarded
: as a superpostion of a bunch of input states. however that is a useless
: way of viewing it unless some observatin of the the single output state
: can be made which will give the desered answer. Very very very few
: problems have been found which fit the latter requirement-- essentially
: only factoring or discrete logs (Shor's original algorithm). In addition
: Grover found a search algorithm which is reputed to decrease a search
: time by a factor of a square root.
All right, this explains what the original poster objected to in that
article. However, I am puzzled here. Suppose one is trying to search for
the key that causes a given ciphertext block to decrypt to a known
plaintext block in DES.
The algorithm for solving that seems simple enough: using the 56
superposed bits as the key, decrypt the ciphertext block to form a
plaintext block. XOR this result with the known plaintext block. If the
result is zero, then take the particular value of the key used, and - is
this where the problem arises?
if the problem is that there is no good way of collapsing the wave
function and leaving 56 bits of data behind, one can simply repeat the
computation 56 times: if bit n of the key is 1, then store a bit in
"observed" memory.
As I understand it, quantum computers are still hoped to be able to
execute programs consisting of computational steps, although there are
other models of quantum computation that are less elaborate.
John Savard
--
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: THE NSAKEY
Date: Mon, 06 Sep 1999 04:42:21 GMT
In article 7quhee$ppg$[EMAIL PROTECTED],
[EMAIL PROTECTED] (David Wagner) wrote:
In article [EMAIL PROTECTED],
Guenther Brunthaler [EMAIL PROTECTED] wrote:
But as the president of an US-company that is dealing with
cryptography, he undoubtedly has to make at least some minor
provisions to government agencies, or they would shut down his company
one way or the other.
So Mr. Schneier has certainly to be very careful about what he's
saying, especially regarding alleged government intrusion attempts
into popular software (unless proven and verified already).
I call bullshit. You're making allegations that are absolutely unfounded.
Schneier has been outspoken against _many_ of the US government's crypto
policies; some might say that he is one of the biggest thorns in their side.
Please take personal attacks like these elsewhere.
How could one consider that an attack. He was if anything explaining why
Bruce anwsers many of the things the way he does. Before I just thought it
was pure arragance and hate for those he considers lower than himself. But
this guy gave reasons for some of Bruces anwsers. Bruce is not a thorn in the
US government crypto. He is after all helping to sucker people into using the
coming AES candidate. How could that be thought of as a thorn. Know maybe
I am a thorn but. Since I don't have a company no one belives so I am less of
a threat but still a small thorn.
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] (Johnny Bravo)
Subject: Re: IDEA- safe?
Date: Sun, 05 Sep 1999 23:02:09 GMT
On Sun, 05 Sep 1999 02:31:00 GMT, Tom St Denis
[EMAIL PROTECTED] wrote:
Can we do simple math?
64 - 56 = 8
8 * 1.5 years = 12 years.
Wouldn't that be 2^(64-56) times harder? not 64-56 times
