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
pa
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 a
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]
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
Cryptography-Digest Digest #747
Cryptography-Digest Digest #747, Volume #9 Tue, 22 Jun 99 09:13:03 EDT
Contents:
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Damian
Weber)
Re: Phone scrambler : what encryption used ? (sb5309)
Weakness of split PGP keys? (Anonymous)
Re: Sexual Contact Privacy :) (Karel Wouters)
Re: Phone scrambler : what encryption used ? ("Lassi Hippeläinen")
authentication wish list (Eric Boesch)
Re: authentication wish list ("Lyal Collins")
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (DJohn37050)
A different method of encryption ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Damian Weber)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 22 Jun 1999 08:35:27 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) writes:
> check out www.certicom.com, look at ECDSA white paper, for example.
>
> The basic idea is that the hard math problem that ECC is based on appears
> harder than the hard math problem that RSA is based on. There are no known
> subexponential-time algorithms to solve a suitable elliptic curve problem. [...]
Except from special cases.
Polynomial time for #E(Fp)=p.
Subexponential time if #E(Fq) divides q^k-1 for small k.
-- Damian
--
From: sb5309 <[EMAIL PROTECTED]>
Subject: Re: Phone scrambler : what encryption used ?
Date: Tue, 22 Jun 1999 17:01:18 +0800
Hi Dan, are you still reading this thread ?
Any web link to a description of A5 algorithm ?
Thanks.
Dan Moschuk wrote:
> Last I checked A5 was a popular algorithm in cellular phones (I know it was
> quite popular in Europe at least, I don't know if North America uses it).
>
> Dan
--
Date: Tue, 22 Jun 1999 11:44:05 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Weakness of split PGP keys?
Hi There.
Say I have a PGP key which has been created with PGP 6.0.2, and is split
into 20 parts. If 19 of these parts are known to an attacker, is the key
any less secure than if say only one part was known?
Thanks.
--
From: Karel Wouters <[EMAIL PROTECTED]>
Subject: Re: Sexual Contact Privacy :)
Date: Tue, 22 Jun 1999 12:20:06 +0200
On 20 Jun 1999, Doug Goncz wrote:
> It is for the good of the public that the government or a health agency might
> wish to keep records of sexual contacts between people. On the other hand, the
> individuals involved usually wish to retain this information as private. There
> is the possibility that an agency could misuse the information.
You'll have to define sexual contacts ...
and as showed in the past year, Americans may have some problems with that
:-
("I did _not_ have any sexual relationship with Ms. ")
This sounds like flame bait ...
[snip]
Karel w
--
From: "Lassi Hippeläinen" <[EMAIL PROTECTED]>
Subject: Re: Phone scrambler : what encryption used ?
Date: Tue, 22 Jun 1999 13:27:39 +0300
I'm not Dan, but I might help a bit...
A5 is a stream cipher that xors the data with output from a PRNG. Sort
of pseudo-OTP. The exact algorithm has never been published officially.
Naturally somebody eventually leaked the information, and soon enough A5
was found to be less secure than promised.
A5 is not only popular, it is THE algorithm used in GSM and its
derivatives. Most likely also in the 1900 MHz variant in America.
More information at http://jya.com/crack-a5.htm
-- Lassi
sb5309 wrote:
>
> Hi Dan, are you still reading this thread ?
>
> Any web link to a description of A5 algorithm ?
>
> Thanks.
>
> Dan Moschuk wrote:
>
> > Last I checked A5 was a popular algorithm in cellular phones (I know it was
> > quite popular in Europe at least, I don't know if North America uses it).
> >
> > Dan
--
From: Eric Boesch <[EMAIL PROTECTED]>
Subject: authentication wish list
Date: Tue, 22 Jun 1999 12:50:27 +0200
Can one achieve all of these goals simultaneously? All the
methods I know of fall short.
Shortness: My password is short and easily memorized (a weak secret).
Trustlessness: I need trust no one and no machine, except possibly
the machine I type my password into. No other person or machine
knows my password or can otherwise assume my identity.
Transportability: I need only my password in order to authenticate
myself, as long as I have access to the network and to client
programs that implement this protocol.
Globality: I can use my password to prove my identity to anyone on the
network (this may be via the authority of a certifying authority,
key server, etc.).
Uncrackability: I can detect and stop dictionary/brute-forc
