Cryptography-Digest Digest #747
Cryptography-Digest Digest #747, Volume #13 Sun, 25 Feb 01 14:13:00 EST
Contents:
Re: super-stong crypto, straw man phase 2 (William Hugh Murray)
Re: RSA - public key exponents and plain text. (William Hugh Murray)
Rabin's IDA in Java ?? (Yaniv Azriel)
Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher) ("Henrick
Hellström")
Re: Tempest (Mok-Kong Shen)
Re: Encrypted Email for Business Documents (Peter Harrison)
Re: Simple, possibly flawed, stream cipher ("Scott Fluhrer")
Re: super-stong crypto, straw man phase 2 (Nicol So)
Diffie-Hellman via Complex Associative Hash Functions (Jim Steuert)
From: William Hugh Murray [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: super-stong crypto, straw man phase 2
Date: Sun, 25 Feb 2001 16:58:28 GMT
Nicol So wrote:
William Hugh Murray wrote:
... going from 15 to16 rounds for the DES adds
both complexity and protection; going from 16 to 17 adds complexity but
no additional protection. The upper bound of the protection comes from
the brevity of the key. ...
I don't think we know enough about DES to be able to say that. There may
be more efficient attacks than currently known/published. And round 17
may make such attacks less effective or less efficient. Unless we know
that no such attacks exist, we really cannot say for sure that round 17
adds no protection.
It is not necessary to know that there is not a more efficient attack than
brute force. It is sufficient to know that brute force against the key is
the most that anyone will spend. That is to say, an exhaustive attack
against the key is the most that any one will spend without regard to what
else they know. They may not spend that much if they know a more efficient
attack but they will clearly not spend more. (Of course, I have trouble
believing that if I knew a cheaper attack that it would benefit me more to
keep that fact a secret than to disclose it, but then, DES was merely an
example.)
What differential cryptanalyis told us was that, for the DES, there was a
subtle balance between the number of rounds and the length of the key. A
longer key would not add much protection if the number of rounds was held
constant. Additional rounds would not add much protection if the key were
kept constant. Until Biham and Shamir published, many people thought that a
longer key, for example, 64 bits, which would raise the cost of an exhaustive
attack dramatically but not that of differential cryptanalysis, would add
protection.
(Of course, since the conditions for differential cryptanalysis are not
practically met, it might add protection to lengthen the key. This is true
IFF differential cryptanalysis is the only attack whose cost is determined by
the complexity of the cryptogram. As I was trying to suggest when I started
this thread, DC is a valuable tool, not because it lowers the cost of
recovering a message without the key (which is the criteria that I thought
Doug Gwyn was using) but because it gives us a way to compare the complexity
of otherwise similar algorithms, e.g., another Feistel algorithm with
different s-boxes or a different number of rounds.)
--
Nicol So, CISSP // paranoid 'at' engineer 'dot' com
Disclaimer: Views expressed here are casual comments and should
not be relied upon as the basis for decisions of consequence.
--
From: William Hugh Murray [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Subject: Re: RSA - public key exponents and plain text.
Date: Sun, 25 Feb 2001 17:01:17 GMT
Rich Wales wrote:
Tony L. Svanstrom wrote:
Yeah, but this isn't about PGP... Basically I'm going to allow
people to send me encrypt messages by using RSA directly on it.
If you're going to use RSA directly, be sure you've studied it very
carefully (including recent research results) in order to avoid the
known security pitfalls.
You can start by reading Zimmerman on the limitations of PGP/
Remember that RSA is slow in comparison with symmetric algorithms; this
is one reason why PGP doesn't use RSA to encrypt the actual cleartext.
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
--
From: Yaniv Azriel [EMAIL PROTECTED]
Subject: Rabin's IDA in Java ??
Date: Sun, 25 Feb 2001 19:07:34 +0200
has any one source code for Rabin's Information Dispersal Algorithm in
java ?
(I found C++ Crypt++ source but it makes too many calls to other
parts of the lib and looks a pain to port..)
--
From: "Henrick Hellström" [EMAIL PROTECTED]
Subject: Improved stream cipher? (was: Re: Simple, possibly flawed, stream cipher)
Date: Sun, 25 Feb 2001 18:21:19 +
Cryptography-Digest Digest #747
Cryptography-Digest Digest #747, Volume #12 Fri, 22 Sep 00 14:13:01 EDT
Contents:
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: State-of-the-art in integer factorization ("Sam Simpson")
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Tying Up Loose Ends - Correction ("Trevor L. Jackson, III")
Re: State-of-the-art in integer factorization (JCA)
Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment
(DJohn37050)
Re: IBM analysis secret. (DJohn37050)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Music Industry wants hacking information for cheap (Scott Craver)
Re: What am I missing? (Scott Craver)
Re: 3DES - keyoptions ("Neil McKeeney")
Re: t (rot26)
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Fri, 22 Sep 2000 14:04:26 GMT
Mok-Kong Shen [EMAIL PROTECTED] wrote:
: Tim Tyler wrote:
: SCOTT19U.ZIP_GUY [EMAIL PROTECTED] wrote:
: : [EMAIL PROTECTED] (Benjamin Goldberg) wrote:
: :SCOTT19U.ZIP_GUY wrote:
: : [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
: : Tim Tyler wrote:
: : Mok-Kong Shen [EMAIL PROTECTED] wrote:
: : : If my message is over one hundred bytes, do you think
: : : that I need to care about wasting 5 bits?? [...]
: :
: : At worst, this can reduce the size of keyspace by a factor of 32.
: :
: : Sorry, I don't understand. What do you mean by 'keyspace'
: : here? This is the message space. The message gets longer
: : by 5 bits. There is no information in the above of how
: : big the key is. [...]
: :
: : I thought we are talking about compressing then ecnrypting.
: : If you always add 5 zeros or any other fixed amount of bits
: : after a compressed string or any file for that matter which is
: : then encrypted. The attacker know what the last few bits are
: : and throws out keys that don't match. So if the last five bits
: : of a file are known then it means you reduce your key space by
: : 5 bits.
: :
: :Reducing the message space by x bits does *not* reduce the keyspace by x
: :bits... How much the keyspace is reduced depends on the unicity
: :distance.
[...]
: If one was *replacing* five bits at the end of the message by 0s,
: the effect would depend on the unicity distance [because those
: bits might have been known already].
: No. [...]
I believe what I wrote was correct.
: Consider this: Encryption algorithm A encrypts, with
: a key K, blocks of 64 bits and produces ciphertext of
: same number of blocks of same lengths. Encryption
: Algorithm B uses the key K to do the same and append
: at the end 5 0's. [...]
That's different from replacing symbols at the end of
a message - which is what I said I was discussing.
: Now the ciphertext of algorithm B is longer than the ciphertext of
: algorithm A. Does that matter excepting the transmissin cost?
There's five "0"s worth of known plaintext.
: Where does the 'keyspace' play a role here at all?
The known plaintext allows you to reject keys. You might not otherwise
be able to do this, or might not be able to do it with such speed,
or certainty. This reduces the effective number of keys that need
to be considered in more depth. It might (or might not) make a
difference to the time taken to break the system.
: That's not what David was talking about. David is discussing the
: effect of adding an additional section of known plaintext to the
: end of the file. This normally has the effect of decreasing the
: keyspace by almost exactly five bits - provided the effective
: keyspace doesn't go negative, of course.
: No. [...]
I think what I wrote was correct.
: He was criticizing my end-of-file symbol taking up extra bits. [...]
Yes. He also discussed the possible costs of reserving a symbol
for this purpose.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Breast is best.
--
From: "Sam Simpson" [EMAIL PROTECTED]
Crossposted-To: sci.math
Subject: Re: State-of-the-art in integer factorization
Date: Fri, 22 Sep 2000 15:21:58 +0100
Erm, RSA and DH equivalents were found by GCHQ prior to the public
disclosures. Your point was? ;)
Just because euro/asia crypt publish QS/NFS papers, how does this
reflect upon the abilities of NSA / GCHQ etc?
--
Sam Simpson
Comms Analyst
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption
Delphi Crypto Components. PGP Keys available at the same site.
Tom St Denis [EMAIL PROTECTED] wrote in message
news:8qfefu$g2v$[EMAIL PROTECTED]...
In article 8qedb0$c49$[EMAIL PROTECTED],
[EMAIL PROTECTED] (Ed Pugh) wrote:
Bob Silverman ([EMAIL PROTECTED]) writes:
Nothing has been written. Improvements have been only
incremental.
(i.e
Cryptography-Digest Digest #747
Cryptography-Digest Digest #747, Volume #11 Wed, 10 May 00 07:13:00 EDT
Contents:
Re: Q: Searching for authentication protocols (=?iso-8859-1?Q?Tom=B4s?= Perlines
Hormann)
TLAs (was: Re: Tempest Attacks with EMF Radiation) (Jonathan Thornburg)
Re: Scary Possibility: Ticklish Chips (Jonathan Thornburg)
Re: Prime Generation in C,C++ or Java ("User923005")
Re: An argument for multiple AES winners ("Sam Simpson")
Re: Why no civilian GPS anti-spoofing? / proposal (Jonathan Thornburg)
Open source cryptography library: BeeCrypt (Bob Deblier)
Re: F function. (Mark Wooding)
Re: Some pencil and paper cyphers (Roger Fleming)
Re: Why no civilian GPS anti-spoofing? / proposal (Thomas Schmidt)
Re: More on Pi and randomness (Tim Tyler)
From: =?iso-8859-1?Q?Tom=B4s?= Perlines Hormann [EMAIL PROTECTED]
Crossposted-To: comp.security.misc
Subject: Re: Q: Searching for authentication protocols
Date: Wed, 10 May 2000 10:26:35 +0200
Strong password authentication protocols like SRP and SPEKE also exchange
a symmetric session key as a byproduct of successful authentication.
You can use this key to provide session integrity and confidentiality.
I have printed out your papers about it, and will read through them
carefully.
BTW: can you tell me who is succesfully applying your protocol? Has it
been (crypto-)analysed from third parties???
Do you know an evaluation vs. other well-known protocols?
Thanks for you informations...
--
Tom Wu* finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
--
Quick answering: mailto:[EMAIL PROTECTED]
Check it out: http://www.weh.rwth-aachen.de/~tomas
Do it Now!
:o) Tomás Perlines (o:
--
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: TLAs (was: Re: Tempest Attacks with EMF Radiation)
Date: 10 May 2000 10:58:28 +0200
In article 8f0pl8$[EMAIL PROTECTED],
Guy Macon [EMAIL PROTECTED] wrote:
What really ticks me off is Asynch Transfer mode. Uh, fellows, the
acronym "ATM" is already taken...
Only in some parts of the world. The thing you put a bank card into
to get money, which is an "ATM" (Automatic Teller Machine) in Canada
and the USA, is a "bankomat" in Europe.
--
-- Jonathan Thornburg [EMAIL PROTECTED]
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Seen on usenet:
Q: "If we're not supposed to eat animals, why are they made of meat?"
A: "If we're not supposed to eat people, why are they made of meat?"
--
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Scary Possibility: Ticklish Chips
Date: 10 May 2000 11:02:49 +0200
zapzing wrote:
Here's something to keep you awake at night:
What if some of the chips for doing DES etc. have
been made "ticklish" , that is what if some
sort of irritant, such as a dose of radiation
or an electrical input that is out of band
would prompt the chip to divulge its key.
In article [EMAIL PROTECTED],
Volker Hetzer [EMAIL PROTECTED] wrote:
Much easier. You design a chip. You give
the design to a company for manufacturing.
Manufacturer has connections to government
and - your chip has an undocumented debug
feature triggered by a certain combination on
your 100+ pins or a specific fluctuation in the
power supply.
More generally, anyone along the way can introduce hardware backdoors,
just as anyone along the software path can introduce software backdoors.
The following (very funny) posting by Henry Spencer to the Linux-IPSEC
mailing list from about 6 months ago makes this point quite well:
## http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
_
Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet
_
* To: Linux IPsec [EMAIL PROTECTED]
* Subject: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
protected 100Mbit Ethernet
* From: Henry Spencer [EMAIL PROTECTED]
* From: [EMAIL PROTECTED]
* Date: Thu, 16 Sep 1999 10:48:52 -0400 (EDT)
* In-Reply-To: [EMAIL PROTECTED]
* Reply-To: [EMAIL PROTECTED]
* Sender: [EMAIL PROTECTED]
_
William H Geiger writes:
I don't know if you still follow the CP list but we have
been having a long debate on the trustworthiness of Intel
hardware, especia
Cryptography-Digest Digest #747
Cryptography-Digest Digest #747, Volume #10 Thu, 16 Dec 99 00:13:02 EST
Contents:
Re: Deciphering without knowing the algorithm? (CLSV)
Re: which is safer for creating session keys (Hanna Pehrson)
Re: Non-linear PRNGs (Hanna Pehrson)
Re: Non-linear PRNGs (Tim Tyler)
Re: Non-linear PRNGs (David Wagner)
Re: Prime series instead (Re: Pi) (Matthew Montchalin)
Re: Deciphering without knowing the algorithm? (SCOTT19U.ZIP_GUY)
Invitation to our homepage ("(ÁÖ)»ó¾Æ´º¸Åƽ")
"Day of Deceit" by Robert Stinnett (Anonymous)
Re: Prime series instead (Re: Pi) ("Trevor Jackson, III")
Re: Why no 3des for AES candidacy (Uri Blumenthal)
Re: Prime series instead (Re: Pi) (Matthew Montchalin)
Re: Off topic -- 4 year old ("r.e.s.")
Re: Scott's Screaming Security Method (lobsterboy)
From: CLSV [EMAIL PROTECTED]
Subject: Re: Deciphering without knowing the algorithm?
Date: Wed, 15 Dec 1999 23:18:34 +
"SCOTT19U.ZIP_GUY" wrote:
[...] Yes I know not all the good cryptoheads live in the US
but what makes you think the NSA would not kill or silence
them if they are precieved as a threat. I though just this last
year there was a strange death of a European expert. Do
you really thing the NSA would let some one in Europe
make real progress who was not controlled directly by
them.
Well I wasn't talking specific of Europe. Asia has many
bright cryptographers, they can also be found in the Middle East,
maybe some are in Africa and South Amerika. The former Soviet Union
probably has more than we can count.
Some are working for agencies like NSA (i.e. out of reach),
many of them work for universities and companies. Their
safety lies in their numbers. There are just too much to
threaten, bribe or kill. But this kind of discussion belongs
to alt.conspiracy.
Don't forget even the Swiss are in bed with the NSA
you do remember how they modifed the swiss crypto equipment
so as to help in spying.
I have heard the rumors. But remember that Crypto AG
can not really be considered a member of the open cryptographic
community. They use many (company)secret algorithms.
Breaking a cipher costs effort. So if someone is willing to
take time to look into a design on this forum it is a favour.
Yes I did consider it a favor. And I understanf Mr BS and
friends have looked at my stuff but don't have the balls to say
much about it. I think it is to embarassing for them.
Well, maybe your cipher is hard to understand and/or break.
This does not mean per se that the security is as high as you
claim it is. Most attention these days goes to the AES contest
which is the most important cryptographic event
of this moment. So it is logical to see more cryptanalysis
on the contestants than on your (probably complex) cipher.
Regards,
Coen Visser
--
From: Hanna Pehrson [EMAIL PROTECTED]
Subject: Re: which is safer for creating session keys
Date: Thu, 16 Dec 1999 00:55:36 +0100
Tom St Denis wrote:
Which is safer hashing KEY+SALT or SALT+KEY? I meant the actual order
in which the data is stored. [or does it matter at all]. I am using
SHA-1 as the hash btw.
I ask this because I have been fiddling with Peekboo which uses
KEY+SALT format, and I wonder if that is ok. Normally if KEY+SALT were
under 256 bits it wouldn't matter with sha since it expands them with
thourough mixing, however in peekboo I hash the hexidecimal copy of
both so it's actually 576 bits of data being hashed.
This paper discusses some vulnerabilities in MACs built on hash functions,
in particular analysis of using keys as prefix, suffix and envelope for
the message;
B. Preneel and P. van Oorschot, MDx-MAC and building fast MACs from hash
functions,
ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/preneel/mdxmac_crypto95.ps.gz
/Pell
--
From: Hanna Pehrson [EMAIL PROTECTED]
Subject: Re: Non-linear PRNGs
Date: Thu, 16 Dec 1999 01:32:07 +0100
David Wagner wrote:
In article [EMAIL PROTECTED], Pelle Evensen [EMAIL PROTECTED] wrote:
Side note, has anyone studied the cryptographic properties of multiply with
carry generators?
What cryptographic properties?
Sorry for being vague. In particular, how easy it would be to deduce the
state of a generator of this kind, based on its output?
All multiplication and addition is mod 2^w.
h = w / 2
m[] are constants satisfying m[x] * 2^h -1 is prime.
s[] is the state of the generator
m[] and s[] are the same size
For each output of h bits, do
c' = m[x-1] * s[x-1] + m[x-2] * s[x-2] + m[x-...] * s[x-...] +
c / 2^h
s[x] = c' / 2^h
output = s[x]
This assuming m[] is kept secret.
/Pell
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Non-linear PRNGs
Reply-To: [EMAIL PROTECTED]
Date: Thu, 16 Dec 1999 0
