Cryptography-Digest Digest #24
Cryptography-Digest Digest #24, Volume #14 Tue, 27 Mar 01 16:13:00 EST
Contents:
Re: Idea - (LONG) (Bertrand)
Re: Malicious Javascript in Brent Kohler post (Povl H. Pedersen)
Re: Large numbers in C (512 bits or more) ("Joseph Ashwood")
Re: DH/DSS ("Joseph Ashwood")
Re: compression ratio as a predicter of cipher strength ("Joseph Ashwood")
Re: Deny Anon Remailers access to this newsgroup (Jim D)
Re: Deny Anon Remailers access to this newsgroup (Jim D)
Re: Newbie wants to shuffle... ("Joseph Ashwood")
Crypto" by Steven Levy E-Book Posting ("Scheidsrechter")
Re: DH/DSS (DJohn37050)
Re: Idea - (LONG) (Mok-Kong Shen)
Re: Crypto" by Steven Levy E-Book Posting (Mok-Kong Shen)
Re: Newbie wants to shuffle... ("Henrick Hellström")
Re: RC4 test vectors after gigabyte output?. (Luis Yanes)
From: Bertrand [EMAIL PROTECTED]
Subject: Re: Idea - (LONG)
Date: Tue, 27 Mar 2001 13:30:40 -0400
Il faudrait d'abord lire ce que j'ai propose.
J'ai signe mes posts sous trois noms differents "br", "amateur" et
"bertrand".
Lis d'abord ce que j'y exprime comme idees avant de repondre
brutalement.
Merci.
Erwann ABALEA wrote:
Right now, you still haven't proved that you could be trusted as a good
cryptographer. Therefore, your criticism about my ignorance in
cryptography is of no value...
But that doesn't matter. After all, it's just talk, isn't it? Please read
on.
I was not talking about your talents as a cryptographer.
I was only talking about your attitude against advices given by people
that are known to be knowledgeable at cryptography. Your only answer is a
proposed challenge to break your poor algorithm. You still don't seem to
understand that even breaking something weak requires some effort, which
at a simple human level can be too much, considered the price paid to do
the work (a free challenge is not very interesting).
If your cryptosystem should only prevent your sister from getting your
love letters, then it's OK, your algorithm might be good enough. But
designing a cryptosystem that could be able to resist to attacks from
motivated attackers (that means with a lot of money, and a lot of
motivated people) needs some real hard work, counted in months or years of
work. But the design of such a cryptosystem can only be engaged after some
years of cryptanalysis and working with already known cryptosystems.
So try to break some known-to-be-breakable cryptosystems, publish your
work so your reputation could be established, and then your *assumptions*
about the strength of a cryptosystem could be considered of value.
But right now, you're designing your system, you only have a vague idea of
what it's strength is (what is the order of operations or memory needed to
break your system with a 12 bits key (you said it's "hard"... a 12 bits
keyspace covers only 4096 different elements, the brute force attack is
trivial to deal with) or more?), so *YOU* have to prove your system is
strong. And such a *proof* can only come from heavy math work...
You've been given some advices to help you build such a proof (either a
proof that it's really strong or not), and your only answer is "hey, just
crack it!". That's a kid behaviour.
If you don't understand the answers given to you, say so.
If you think people didn't understand your system, and the advices are not
relevant enough, then enhance your communication level, and try to post
either:
- a clear and precise formal description of your algorithm (in english,
since that's the language of choice to reach the most people on the
Internet).
- a C source code that could be easily compiled on any Unix workstation,
and a set of test vectors to compare the results obtained by the guys
cool enough to try your code with the reference ones (yours). Please
provide useful comments in your source code, that may prevent some
future questions.
I'm no cryptanalyst but I'm interested in cryptography since several
years, I often read books and practice at home, I use cryptography in my
everyday work (I work for a VeriSign affiliate in Europe, in the RD lab),
I often talk with very good cryptographers (some of them are very kind
people, and well known).
Therefore I can't say I'll break your cryptosystem. But I'd like to try,
even with my really short free time. I'm a software developer at first, so
my preferred approach would be to compile a C code, run it to get some
results, and work on them... The result (or non-result) of my work is of
no value for the few very talented people, but we both are still not
playing in the same playfield as them.
I repeat, be humble.
Thanks for having read so far.
On Tue, 27 Mar 2001, Bertrand wrote:
Who has spoken about "perfect ciph
Cryptography-Digest Digest #24
Cryptography-Digest Digest #24, Volume #13 Sat, 28 Oct 00 09:13:00 EDT
Contents:
Re: Encryption scheme ideas? (Dido Sevilla)
Re: Psuedo-random number generator (Dido Sevilla)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tim Tyler)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tim Tyler)
Re: Psuedo-random number generator ("Nick Field")
Re: Psuedo-random number generator (Thomas Pornin)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tom St Denis)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tom St Denis)
Re: BEST BIJECTIVE RIJNDAEL YET? (Tom St Denis)
Re: very large mult. div. (Tom St Denis)
Re: very large mult. div. (Tom St Denis)
Re: how i decode this? (Tom St Denis)
Re: Psuedo-random number generator (Paul Schlyter)
Re: End to end encryption in GSM (Marc)
Re: how i decode this? (Simon Johnson)
From: Dido Sevilla [EMAIL PROTECTED]
Subject: Re: Encryption scheme ideas?
Date: Sat, 28 Oct 2000 17:09:32 +0800
Ethics wrote:
Hey all,
Just though you might be able to help me identify the encryption scheme
used to encrypt this...
The word is : juris
The encrypted word is: [x\p_Cr|guh@XP
ANY ideas would be helpful
Well, it would help if you could tell us the particular program that
produced the output, seeing as you happen to have both plaintext and
ciphertext pairs. Someone on the list might be familiar with it, and
could give you technical details on what encryption is actually used.
--
Rafael R. Sevilla [EMAIL PROTECTED] +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
--
From: Dido Sevilla [EMAIL PROTECTED]
Subject: Re: Psuedo-random number generator
Date: Sat, 28 Oct 2000 17:37:21 +0800
slak- wrote:
Would it not be feesable to use your sound blaster to scan a number of
radio-frequencies and do a series of calculations based on the results to
generate a seed? I've been thinking about it, but my mediocre programming
knowledge doesn't let me do too much, although I'm learning :)
The radio signals don't have to be from some local frequency. Could you not
simply check extremely high frequencies that would be severely affected by
the sun, for instance.
The trouble is the sound blaster is not a radio card; you can't use it
to scan RF noise from external sources, at least not without some sort
of external hardware. And if you're going to be having external
hardware anyway, why not just have a dedicated hardware RNG anyway?
There are a number of resources I've found on the Internet describing
how to build such a thing out of components you can buy at your local
radio shack or whatever. One of the simplest I've found uses the
base-emitter junctions of a couple of transistors to generate noise from
avalanche multiplication, the two transistors, plus a TTL inverter
should be good enough to generate a Gaussian-distributed random bit
generator that you can easily connect to a parallel port with no
hassle. And then use a 20:1 SHA-1 to decorrelate the noise and have
your random seed. You may need to shield the transistors to prevent the
noise from becoming biased by external sources, though.
--
Rafael R. Sevilla [EMAIL PROTECTED] +63 (2) 4342217
ICSM-F Development Team, UP Diliman +63 (917) 4458925
OpenPGP Key ID: 0x0E8CE481
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: BEST BIJECTIVE RIJNDAEL YET?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 28 Oct 2000 09:39:44 GMT
Tom St Denis [EMAIL PROTECTED] wrote:
: [EMAIL PROTECTED] wrote:
: Tom St Denis [EMAIL PROTECTED] wrote:
: : [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
:
: : If you folks check at comp.compression you we see a note
: : from Matt Timmermans on his super bijective PPM compressor
: : with a built in bijective RIJNDAEL in modied CBC mode. [...]
:
: : http://www3.sympatico.ca/mtimmerm/bicom/bicom.html
:
: : Perhaps us "know nothing" people prefer to leave our security to
: : security related algorithms.
:
: I believe that's why the product includes a bijective version of
: Rijndael [...]
: Of course Rijndael is bijective it's a friggin block cipher.
That's not the point. Have you considered issues related to dealing with
files which are not exact multiples of the Rijndael block length?
Can you point me at any other implementation of Rijndael where decrypting
an arbitrary cyphertext, and re-encrypting again with the same key
produces exactly the same file?
: The PPM bijective compressor is intended to minimise known probable
: plaintext before encryption, reduce bandwidth and maximise the
: number of possible decrypts that look like plausible messages.
: While the PPM codec may reduce the redundancy in the plaintext I have
: yet to hear of any cryptosystem broken because the plaintext was ASCII
: text only.
I think you need to qualify this to avoid it bein
Cryptography-Digest Digest #24
Cryptography-Digest Digest #24, Volume #12 Wed, 14 Jun 00 10:13:01 EDT
Contents:
Re: DPmax of Feistel Construction (Mark Wooding)
Re: Man in the middle attacks (Mark Currie)
Re: Why the golden ratio? (Runu Knips)
Re: FIPS-186 vs. FIPS-186-2 (Tim Tyler)
Re: CRC Programming Help... Please!! (Runu Knips)
Re: McTER 2 (manual crypt) (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Re: Why the golden ratio? (Volker Hetzer)
Re: Random sboxes... real info (Rex Stewart)
Re: Why the golden ratio? (Runu Knips)
Re: Random sboxes... real info (Rex Stewart)
Re: An interesting page on the Rabin-Miller PP test (Andrew John Walker)
Re: Why the golden ratio? (Volker Hetzer)
Re: Updated: Evidence Eliminator Dis-Information Center (Richard Herring)
Re: Cipher design a fading field? (Nicol So)
Re: Cipher design a fading field? (Nicol So)
Application specific SBoxes in Blowfish? ("Sam Simpson")
Re: Updated: Evidence Eliminator Dis-Information Center (Don Barzini)
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: DPmax of Feistel Construction
Date: 14 Jun 2000 08:56:38 GMT
tomstd [EMAIL PROTECTED] wrote:
The DPmax of any n-bit function is at most 2^-n+1
I think you mean `at least'. The DPmax of a function can be 1.
Consider XOR with a constant.
-- [mdw]
--
Subject: Re: Man in the middle attacks
From: [EMAIL PROTECTED] (Mark Currie)
Date: 14 Jun 2000 09:08:33 GMT
In article 8i31co$9n4$[EMAIL PROTECTED], [EMAIL PROTECTED] says...
I've been reading my copy of Applied Cryptography, looking at ways of
defeating man in the middle attacks.
All the methods in the book use a Trusted Person to make sure the
protocol works.
Can anyone please point me in the direction of a protocol that works
with two nodes - if such a thing exists. It's been rattling around in
my head for the last week and I can't think how I would make it work.
Thanks,
Sent via Deja.com http://www.deja.com/
Before you buy.
It really comes down to trust/authentication. You cannot beat MTM unless you
have some way of authenticating the message originator. This does not always
require a trusted third party. The most inconvenient way is probably the best,
which is a face-to-face meeting to exchange information which can later be used
for authentication.
Once you have the initial trust bit sorted out, there are many ways to defeat
MTM.
Mark
--
Date: Wed, 14 Jun 2000 11:26:14 +0200
From: Runu Knips [EMAIL PROTECTED]
Subject: Re: Why the golden ratio?
Dido Sevilla wrote:
Does the golden ratio have some properties that these
other numbers don't?
AFAIK there is a simple equotation of pi, e, the golden
number, and 1, I don't remember it exactly but it was
really very simple. Maybe I can find it at home.
However, I believe the fact that the golden number is
related to pi and e puts a little of the glory of those
most important numbers into it. :-)
And hey, its golden ! ;-)
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: FIPS-186 vs. FIPS-186-2
Reply-To: [EMAIL PROTECTED]
Date: Wed, 14 Jun 2000 09:18:07 GMT
Martin Hamann [EMAIL PROTECTED] wrote:
: I found this on the web
: http://csrc.nist.gov/fips/fips186-2.pdf
: It's official date is 27th of july 2000, but as far as I can see it is
: published already.
http://csrc.nist.gov/fips/ says this came out in Feb. 2000.
--
__ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Be good, do good.
--
Date: Wed, 14 Jun 2000 11:40:01 +0200
From: Runu Knips [EMAIL PROTECTED]
Subject: Re: CRC Programming Help... Please!!
Joseph Reuter wrote:
[...] A Cyclic Redundancy Checksum is not a cryptographic hash.
Yep. It was never designed for that purpose.
It's not a hash at all.
No, wrong, its surely a hash function, and also a really
good one for non-cryptographic purposes.
It is an error-detecting code, usually chosen because
it guarantees to detect any burst of errors whose length is less
than the length of the checksum.
Which means its also good to use in hashtables, where each
changed bit should also result in some totally different
hash value.
[...]
A Cyclic Redundancy Checksum (CRC) is linear, and will never be
cryptographically secure!
Yep.
--
Subject: Re: McTER 2 (manual crypt)
From: [EMAIL PROTECTED] (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
Date: Wed, 14 Jun 2000 10:03:06 GMT
In the previous post there is an erron in the listing
pt1$ = "PLAINTEXTONEPTEXTTWOPTEXDPLAINTEXTONEPTEXTTWOPTEXD"
It should have been this:
pt1$ = "PLAINTEXTONEPTEXTTWOPTEXTTHREEPTEXTFOURPTEXTFIVEPTEX"
Hope this didn't caused too much problems
Jacques Thériault
--
From: Volker Hetzer [EMAIL PROTECTED]
Subject: Re: Why t
Cryptography-Digest Digest #24
Cryptography-Digest Digest #24, Volume #11 Mon, 31 Jan 00 13:13:02 EST
Contents:
Re: How much random needed for random (Shawn Willden)
Re: Should I buy the Dr Dobbs CD? (Shawn Willden)
Re: "Trusted" CA - Oxymoron? (Shawn Willden)
Re: Java's RSA implimentation (Shawn Willden)
Re: Output openssl results to memory buffer (Roger Gammans)
Re: NIST, AES at RSA conference ("Trevor Jackson, III")
Re: How to password protect files on distribution CD (Eric Lee Green)
Re: Help needed on peculiar use of cryptography (Eric Lee Green)
Re: Voynich manuscript (Jim Reeds)
Date: Fri, 28 Jan 2000 17:03:00 -0700
From: Shawn Willden [EMAIL PROTECTED]
Subject: Re: How much random needed for random
Scott Nelson wrote:
On Sun, 23 Jan 2000 11:59:15 +0200, "Yoni M." [EMAIL PROTECTED] wrote:
I'm using SecureRandom (java) in my SSL implementation to produce the
random bytes needed for the challanges. My problem is performance, it
takes too long to generate the bytes. If I'm using a simple Random
everything is much faster.
If your problem is performance, then you should consider
a language built for performance, rather than compatibility.
Java is nice for some things, but this isn't one of them.
Java is plenty fast for such an application.
The reason SecureRandom is slow is not because the SHA-1 implementation is
slow, but because of the mechanism used to seed the PRNG. A technique
based on counting the number of times a thread can yield in a certain
amount of time with some other stuff going on (read the docs -- this is
from memory) is used to generate the seed. Once the seed is generated,
the PRNG itself is very fast.
Does anyone knows of a short cut or suggestion how to improve the
performance without reducing security ?
Not in Java.
The language is not really relevant to that question.
Normally, you can speed initialization by keeping a pool
of entropy handy which is then hashed for use. That implies
the ability to write files, which is counter to the Java
philosophy. (and introduces another whole host of problems.)
For your app, this would probably need to be a separate program.
offtopicWriting files is not at all "counter to the Java philosophy",
and in fact Java has some rather nice tools for handling files. Sheesh, I
didn't realize there was still so much Java FUD circulating. Personally,
I use C++ when possible, but Java is very usable, and with a a
just-in-time compiler performance seems to be somewhere between 0.5 and
0.1 times the performance of C, which is just fine in most applications.
In my environment, when building an application that may have to scale up
to very high performance requirements, Java is the language of choice,
because it makes throwing more hardware at the problem so much
easier./offtopic
You could allow the SecureRandom to initialize itself once, and then get
some data from it to write to a file for use in initializing SecureRandom
next time. Of course, this means that the security of your random numbers
is only as good as the security on your randomness pool file (not to
mention the question of whether or not the thread-yield-counting method of
initialization is any good).
If you do have any source of randomness available, it's a good idea to
periodically use the setSeed() method to add randomness to the
SecureRandom internal state. It mixes the new seed data in with the
existing state, meaning it does not reduce entropy. Mixing in the current
time each time the application is started may add a few bits of entropy.
Finally, note that my comments about the internals of SecureRandom (SHA-1)
and the seeding mechanism (the thread-yield-counting thing) only apply to
the Sun implementation of SecureRandom that comes with the JDK. The Java
security framework allows other versions of SecureRandom to be added and
then requested with SecureRandom.getInstance().
Shawn.
--
Date: Sun, 30 Jan 2000 17:16:44 -0700
From: Shawn Willden [EMAIL PROTECTED]
Subject: Re: Should I buy the Dr Dobbs CD?
David A Molnar wrote:
Victor Zandy [EMAIL PROTECTED] wrote:
I found one article in deja.com that says some of the text on the
CD is "garbled". What does that mean? Is it still true of more
recent pressings of the CD?
The first version of the CD had a horrible proprietary Windows-only
interface. It also exhibited problems with missing text or links which did
not work. Actually, "exhibits", since I still have my copy.
Also, garbled text, unreadable images and generally very poor quality in many
of the books (but not all).
The current version of the CD consists of .pdf files and by all accounts is
a fine product and worth buying.
I hadn't heard they had a new version... I'm going to have to see if I can get
an upgrade.
Shawn.
--
Date
Cryptography-Digest Digest #24
Cryptography-Digest Digest #24, Volume #10 Tue, 10 Aug 99 15:13:04 EDT
Contents:
Between Silk Cyanide - two questions (Phoeper)
Re: How to keep crypto DLLs Secure? ("Simon Dainty")
Re: Between Silk Cyanide - two questions (John Savard)
Re: NIST AES FInalists are (Bruce Schneier)
Re: AES finalists to be announced (Bruce Schneier)
Re: AES finalists to be announced (Bruce Schneier)
Re: Techweb crypto comedy... (John Savard)
Re: Between Silk Cyanide - two questions (Jim Gillogly)
Re: NIST AES FInalists are (Helger Lipmaa)
Need decrypt Diskreet disk (NU 8.0) or calculate password ("Vasiliy Khalak")
Need decrypt Diskreet disk (NU 8.0) or calculate password ("Vasiliy Khalak")
Re: Why does MS-Visual C++ ABSOLUTELY REQUIRE . . . (Pretty Boy Mohandas)
From: [EMAIL PROTECTED] (Phoeper)
Subject: Between Silk Cyanide - two questions
Date: 10 Aug 1999 17:01:20 GMT
Just finished the book, and two questions occurred to me:
1. Several times, Marks states that a MINIMUM message size is required - why
should giving the cryptanalyst more text reduce the chances of breaking the
message?
2. In the appendix on charting the 'fist' of WT operators, what do the graphs
indicate? The axes are not labelled and it is not clear (to me, anyway) what
they mean.
Thanks,
Phil
--
From: "Simon Dainty" [EMAIL PROTECTED]
Subject: Re: How to keep crypto DLLs Secure?
Date: Tue, 10 Aug 1999 17:31:11 +0100
Martijn van der Kooij wrote in message 7omopg$hk0$[EMAIL PROTECTED]...
The only sure way to have moderate crypto security is to have the crypto
directly inside the compiled EXE, and not within the DLL. I would
appreciate comments.
One way to be sure the dll is not replaced is to use a hash or crc on the
dll. Store the CRC value in the exe and when loading the dll compare its
crc
with this value. You maybe need a few different values if there are
different versions of the dll.
If someone is going to go to all the effort of replacing the DLL with a fake
DLL, then surely they're willing to go that extra step and reverse engineer
the
executable if need be?
There is no viable security for software today.
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Between Silk Cyanide - two questions
Date: Tue, 10 Aug 1999 17:40:54 GMT
[EMAIL PROTECTED] (Phoeper) wrote, in part:
1. Several times, Marks states that a MINIMUM message size is required - why
should giving the cryptanalyst more text reduce the chances of breaking the
message?
One of the cipher systems discussed is a transposition cipher. For that one -
not for the one-time-pad cipher - messages that are too small could give away
some information.
John Savard ( teneerf- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
--
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: NIST AES FInalists are
Date: Tue, 10 Aug 1999 17:30:22 GMT
On Tue, 10 Aug 1999 01:30:21 GMT, "Douglas A. Gwyn" [EMAIL PROTECTED]
wrote:
At what point are competent NSA cryptanalysts going to be brought
into the process, so we can get a soundly based estimate of security?
I believe the NSA is already analyzing the AES submissions, but I
don't believe that "we" will ever get the results of that analysis.
Bruce
**
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
--
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: AES finalists to be announced
Date: Tue, 10 Aug 1999 17:34:40 GMT
On Mon, 9 Aug 1999 19:16:23 GMT, [EMAIL PROTECTED] (Larry
Kilgallen) wrote:
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Bruce Schneier)
writes:
RC6 is suprisingly slow on the Pentium and other simple 32-bit
computers. It is fast on the Pentium Pro, Pentium II, and Pentium
III. It is very suprisingly slow on the new Intel processors that
will be coming out over the next few years.
Hey, you can't have it both ways !
If you are able to predict performance on future processors,
then it can't be _surprisingly_. :-)
I suppose. But I was suprised.
Bruce
**
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
--
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: AES finalists to be announced
Date: Tue, 10 Aug 1999 17:35:13 GMT
On Mon, 9 Aug 1999 12:41:48 -0700, "Jai.Dee"
[EMAIL PROTECTED] wrote:
Bruce,
C
