Cryptography-Digest Digest #681
Cryptography-Digest Digest #681, Volume #12 Thu, 14 Sep 00 19:13:01 EDT
Contents:
Re: RSA Questions (Bryan Olson)
Re: Weaknesses in this algorithm? (Benjamin Goldberg)
Re: [Q] Design criteria for sboxes in Tiger/192 ? (Mok-Kong Shen)
Re: DH - 3DES ([EMAIL PROTECTED])
Re: Dickman's function (D. J. Bernstein)
Re: Looking for Partners (and Investors) ("root@localhost " [EMAIL PROTECTED])
Re: Looking for Implementation Site ("root@localhost " [EMAIL PROTECTED])
Re: 20 suggestions for cryptographic algorithm designers (D. J. Bernstein)
Re: Scottu19 Broken (JPeschel)
"Secrets and Lies" at 50% off (Bruce Schneier)
Re: cellular automata rng? (Tim Tyler)
Re: [Q] Design criteria for sboxes in Tiger/192 ? (Tim Tyler)
Re: Fresh Meat: New Crypto Algorithms Announced (David A Molnar)
Re: DH - 3DES (Tom St Denis)
Re: "Secrets and Lies" at 50% off (Tom St Denis)
Comments TC6a please (Tom St Denis)
Re: Recent crypto text (David A Molnar)
Re: free ssl cert (Paul Rubin)
From: Bryan Olson [EMAIL PROTECTED]
Subject: Re: RSA Questions
Date: Thu, 14 Sep 2000 20:07:11 GMT
Jim Trek wrote:
Does anybody know what goes wrong with RSA
if p or q or both are not necessarily prime?
The modulus must be the product of distinct primes for
encryption to be invertible.
Surely there is still a way to select a d such
that decryption works for the receiver.
If the prime factors of n are
p_1, p_2, ..., p_k (all distinct)
let lambda be the least common multiple of
(p_1 - 1, p_2 - 1..., p_k - 1).
then choose d as the modulo lambda inverse of e.
If RSA becomes weaker, does anybody know how
messages would be decrypted without d?
If the factors get too small, the modulus becomes easier to
factor. The attack is to find d, not to decrypt without it.
I ask these questions because the strength of RSA seems
to depend upon the size of the numbers. The numbers encrypted
by RSA must be large; otherwise, a table could be made...
The table attack is exponential in time and space, and much
more expensive than factoring.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Benjamin Goldberg [EMAIL PROTECTED]
Subject: Re: Weaknesses in this algorithm?
Date: Thu, 14 Sep 2000 20:25:39 GMT
Runu Knips wrote:
Patrick Schultz wrote:
Ok, I see the weakness is in the fact that RC4 is just \xoring a
psuedo-random string with the one-time pad.
No, the problem is that sending an OTP encrypted means that
you always weaken the security of the whole protocol to the
security of the encryition of the OTP. Therefore you can
drop the OTP and use that encrytion directly.
But what if that the plaintext has much structure/guessability, eg being
mostly zeros? If numbers in the range 0..1000 are sent as 4-byte
values, we *know* 2 bytes are 0, and 6 bits of a 3rd byte are also 0.
If we encrypt this data directly with a block cipher, we have quite a
bit of known plaintext, which will significantly assist in breaking that
block cipher. Doing the thing with the OTP means that the block cipher
cannot be so easily attacked.
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: [Q] Design criteria for sboxes in Tiger/192 ?
Date: Thu, 14 Sep 2000 23:01:18 +0200
"David C. Barber" wrote:
As I recall once hearing, DES proved surprisingly resistant to later
developed attacks (differential cryptanalysis) and it was determined that
its S-boxes appeared optimized against that type of attack. When asked, one
of the original designers basically just smiled and did not comment further.
The implication was that the designers knew of the DC attack, and perhaps
others not publicly known, and armored DES against it.
One of the designers of DES acknowledged to have known at
design time the differential analysis technique when the
same was very much (14 years) later re-invented by Biham
and Shamir. It is not unreasonable to conjecture that the
knowledge and capability of the non-public experts are
always ahead of those of the public experts. (Hence
reason to be conservative.)
M. K. Shen
--
From: [EMAIL PROTECTED]
Subject: Re: DH - 3DES
Date: Thu, 14 Sep 2000 20:36:23 GMT
In article 8pr8on$gc7$[EMAIL PROTECTED],
Tom St Denis [EMAIL PROTECTED] wrote:
In article 8pr2pf$8hq$[EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
I'm looking for a reference on how to exchange 3DES keys with Diffie
Helman. What size prime should the DH use to be stronger than 3DES?
Should I just take the first 24 bytes of the DH computed key as the
computed 3DES key or is more processing necessary?
Shoul
Cryptography-Digest Digest #681
Cryptography-Digest Digest #681, Volume #11 Mon, 1 May 00 19:13:01 EDT Contents: Re: Joystick as RNG (Mok-Kong Shen) Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... (jungle) Silly way of generating randm numbers? (JCA) Re: Magnetic Remenance on hard drives. (Thor Arne Johansen) Re: Joystick as RNG (Tom St Denis) Re: Another naive question (James Felling) Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (James Felling) Re: factor large composite (Stanley Chow) Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (James Felling) Re: mod function? (Mok-Kong Shen) Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... (James Felling) Re: Silly way of generating randm numbers? (Mok-Kong Shen) Re: Diff analysis (Baruch Even) From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: Joystick as RNG Date: Tue, 02 May 2000 00:19:35 +0200 "NFN NMI L. a.k.a. S.T.L." wrote: Gravis gamepad? Take a look at the data coming from that puppy. While it's a great joystick (I use it myself), it isn't like a normal joystick. It can only register 8 directions, good for games, bad for crypto. Unless you have some funky new version. I think Tom St Denis is very fond of experimenting with quite a lot of stuffs. This is not bad though, since many discoveries have stemmed from rather arbitrary experiments. M. K. Shen -- From: jungle [EMAIL PROTECTED] Crossposted-To: comp.security.pgp.discuss Subject: Re: S/MIME + Netscape v47 serious problem in symmetric encryption ... Date: Mon, 01 May 2000 18:11:04 -0400 when I'm sending to myself [ encrypted ], received message reports ALL THE TIME 3DES / 168 bits applied cipher [ despite, I never selected it in my configuration ] in netscape, my 1 [ ONE ] only selected cipher is RC2 / 128 bits ] the other people who are reporting to me that they selected cipher is RC2 / 128 bits, in my place, they e-mail's are reporting RC2 / 40 bits ONLY ... Travis Farral wrote: It just seems odd that the issue seems to exist in both the Outlook Netscape mail clients. Two other people I know of experience the same issue with Outlook. So far I don't know anyone who has actually been able to produce a verified 128 bit encrypted mail using digital certificates. I simply stuck with PGP and quit using the Verisign method as I was unsure what was happening behind the scenes. Anyway, it would be interesting to find out why it keeps reporting only 40-bit encryption. -Travis jungle wrote: user error [ my error ] ? NO ... windows error ? the certificate is handled by Netscape not by win95 ... in my understanding ... Travis Farral wrote: I have seen both of these examples as well using Outlook Express 5.00 w/128 bit security and a Verisign digital certificate on Windows 2000 Professional. Outlook 2000 appears to perform the same on the same machine with the same certificate. Is this a problem with Windows and not necessarily with the mail clients? Or is it simply user error and something isn't set right? I beat my head over this several weeks ago and finally gave into the fact that whatever encryption method you set it for isn't necessarily what you will get. -- From: JCA [EMAIL PROTECTED] Crossposted-To: sci.math Subject: Silly way of generating randm numbers? Date: Mon, 01 May 2000 15:13:38 -0700 Reminded the other day about Shanks and his mistake when computing pi to more than 700 decimal places (apparently only the 500-odd first ones are correct) I couldn't help wondering if this might provide a way to generate strings of random integers: Start the computation of pi to some given precision and at some (pseudo) randomly chosen step make a deliberate arithmetic mistake a la Shanks. The digits generated from that point onwards are of course not part of pi any more (at least not in that particular position), and could in principle be used as random digits. Now it is not clear that this procedure might not lead to a trivially predictable strings of digits (short period strings) but it is true that Shanks came up with something that looks convincingly random all right. Is this completely preposterous? -- From: Thor Arne Johansen [EMAIL PROTECTED] Subject: Re: Magnetic Remenance on hard drives. Date: Tue, 02 May 2000 01:01:51 +0200 "NFN NMI L. a.k.a. S.T.L." wrote: Symantec offers data recovery services. The person who posted that such services are not commercially available is a [insert flame here]. Well, at least you did not spell out the flame... I never said that data recovery is not offered commercially. I said that recovery of _overwritten_ data is not commercially available. Since I work for a data reco
Cryptography-Digest Digest #681
Cryptography-Digest Digest #681, Volume #10 Sat, 4 Dec 99 16:13:01 EST
Contents:
Re: What part of 'You need the key to know' don't you people get? (Tim Tyler)
Re: Random Noise Encryption Buffs (Look Here) (Tim Tyler)
Re: Literature on secure systems engineering methodology--pointers (CLSV)
Re: Literature on secure systems engineering methodology--pointers (The Bug Hunter)
NSA competitors (CLSV)
Re: Literature on secure systems engineering methodology--pointers (CLSV)
Re: NP-hard Problems (Bill Unruh)
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Why Aren't Virtual Dice Adequate? ("r.e.s.")
Re: Cryptological discovery, rediscovery, or fantasy? (Brian Chase)
Re: Any negative comments about Peekboo free win95/98 message encryptor (Lame I.
Norky)
1 round Defeats Enigma attacks (UBCHI2)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: cookies (Brian Chase)
DNA based brute-force attacks? (Brian Chase)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
Re: NSA should do a cryptoanalysis of AES (wtshaw)
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: What part of 'You need the key to know' don't you people get?
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Dec 1999 15:27:03 GMT
Rick Braddam [EMAIL PROTECTED] wrote:
: BTW, the thread so far seems to have concentrated on CBC and CFB.
: I've seen little mention of OFB. Does it have the same limited
: scope of affect (2 blocks) as the other two, in spite of its
: resemblance to a stream cipher?
Plaintext information is confined to individual blocks with OFB.
Errors are confined to the block in which they occur.
There's no diffusion of plaintext information between blocks at all.
: An all or nothing method is more secure vs. these forms of attack.
: However, the three letter methods do not weaken the underlying code,
: they merely fail to strengthen it.
: If they fail to strengthen it, then they have failed to satisfy the
: objective for using them, haven't they?
They do strengthen it against some forms of attack. However they fail to
strengthen it against others, and it is those that are the subject here.
: If an all or nothing method is more secure, is the difference in degree
: of security a significant amount?
Unfortunately, the answer to this depends on all sorts of things.
You'd probably have to do a cost-benefit analysis of your circumstances
before being able to make a firm decision.
Security benefits are notoriously hard to quantify, so the value
of hinderance against a certain range of attacks may be hard to put a
figure on.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
May all your PUSHes be POPed.
--
From: Tim Tyler [EMAIL PROTECTED]
Subject: Re: Random Noise Encryption Buffs (Look Here)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 4 Dec 1999 15:37:13 GMT
Anthony Stephen Szopa [EMAIL PROTECTED] wrote:
: Tim Tyler wrote:
: Anthony Stephen Szopa [EMAIL PROTECTED] wrote:
: : You have just discovered true randomness.
:
: Alas, even *if* this is genuinely random - which you will never
: demonstrate - nobody has developed a scheme for extracting this
: information onto a macroscopic scale without introducing bais of
: one type or another.
:
: Until such a scheme is demonstrated, "true atomic randomness" is
: of the same utility to a cryptographer as a "perfectly straight line"
: is to a student of geometry.
: I think you have taken a misguided position and are struggling too much to
: defend it.
Whereas your position appears to be based on faith in the existence of
genuine randomness in subatomic behaviour, and in our ability to
magnify this up to a macroscopic scale, without distorting it at all.
: I think that a very good true random demonstration would be to generate a
: single photon and direct it through a tiny hole. Where it strikes a screen
: on the other side of the hole will be unpredictable within the possible field
: in which it may strike.
I can't predict it /exactly/ - but I know that it will be more likely to
hit near the centre of the field near the edges, and that there will be
radial fringes of probability distribution relating to where it is likely
to hit.
How yo you propose using this source of information to generate a
genuinely random bitstream?
What equipment will you use, and how will it be set up?
Will you use polarised light? Light with random polarisation?
What frequency is your light source? Is it from a lazer?
Is it projecting through a perfect vacuum?
What shape is your "small hole"?
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
COBOL
Cryptography-Digest Digest #681
Cryptography-Digest Digest #681, Volume #9Wed, 9 Jun 99 10:13:02 EDT
Contents:
Re: being burnt by the NSA ("Douglas A. Gwyn")
Re: being burnt by the NSA ("Douglas A. Gwyn")
Re: Using symmetric encryption for hashing (SCOTT19U.ZIP_GUY)
Re: being burnt by the NSA ("Douglas A. Gwyn")
Re: I KICKED HER HARD IN THE CUNT I KNOCKED HER ON HER ASS THEN I STEPPED ON HER
NECK AND WATCHED HER DIE (Sam)
Re: my simple cipher ([EMAIL PROTECTED])
Re: what cipher? ("Douglas A. Gwyn")
Re: KRYPTOS ("Douglas A. Gwyn")
rsa with fpga ("lewis chen")
Re: KRYPTOS ("Kalika")
Break this simple cipher ([EMAIL PROTECTED])
Re: being burnt by the NSA (Nicholas Landau)
Re: being burnt by the NSA (Thomas Pornin)
I challenge thee :) (smoke_em)
Re: rc4 vs. rand() ([EMAIL PROTECTED])
Re: Key lengths vs cracking time (Thomas Pornin)
Re: my simple cipher ([EMAIL PROTECTED])
Re: tomstdenis' simple.c ([EMAIL PROTECTED])
Blowfish or RC4/5 in Visual Basic (Pontus Hanserkers)
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 04:14:01 GMT
[EMAIL PROTECTED] wrote:
The fact still remains that people complain about the NSA (Dave scott
likes to do this) and I have never heard anything from the NSA.
Why should you? I.e., why should they care what D.Scott thinks?
NSA employees aren't allowed to talk about what they do, for the most
part, without first clearing it with their Public Affairs office.
That's too much trouble for something like a message to this forum.
In fact I have seen bad things, such as DES and skipjack. Both
ciphers have been broken which means they are human too.
DES and Skipjack both admirably met their design goals.
DES has just recently *barely* been broken in a published attack,
so it held up far longer than its design lifetime of ten years.
Skipjack hasn't been broken in the general case, to my knowledge.
I have never been in DC, but if I am down there I may take a peek :)
The National Cryptologic Museum is worth a visit.
--
From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: being burnt by the NSA
Date: Wed, 09 Jun 1999 04:16:22 GMT
fungus wrote:
Again, this shows to me that the NSA knows *exactly* what they
are doing.
There are certainly many people on NSA's staff who do know these
things to a depth not realized publicly.
--
From: SCOTT19U.ZIP_GUY [EMAIL PROTECTED]
Subject: Re: Using symmetric encryption for hashing
Date: Mon, 31 May 1999 22:53:12 GMT
In article [EMAIL PROTECTED],
Paul Onions [EMAIL PROTECTED] wrote:
Thomas J. Boschloo wrote:
I have posted this question to news:comp.security.pgp.discuss and
news:alt.security.pgp, but I still feel kind of fuzzy on the
subject.
Can, for example, twofish in cbc-mode (or whatever) be used as a
hashing
function? Could you, as an example, use the string "hash" as a key
to
encrypt a document and take the last few bytes of cyphertext as your
hash for that document?. Would this be safe?
In general, no. Cryptographic hashes are usually assumed to have the
properties of one-wayness and collision-resistance. Using a
block-cipher
in CBC mode provides neither of these.
For example, given the last few bytes of CBC ciphertext we could
simply
"invent" some previous ciphertext and then decrypt it, giving us a
pre-image of the hash. So it wouldn't be one-way.
Also, in CBC mode, if you know the key it's easy to insert plaintext
blocks so that the ciphertext beyond the inserted block is the same
as it was originally. So it's easy to create colliding messages.
One the other hand there are specific constructions to create hash
functions from block ciphers, but I don't have any to hand right now.
Maybe someone more familiar with these techniques will post a
recommendation.
I post to this earler but for some reason I wrote scott16
instead of scott16u but as you know plain vanilla scott16 treats
odd and even length files and it was a TYPO. Any way since
scott19u or scott16u do not use CBC mode and since a bit change
anywhere in the input file affects the whole output file you
could use the last (or front) few bytes as a hash if you wanted
too and not suffer from the some problems as Paul pointed out
above.
(Though I do know that they tend to be rather sensitive to any
weaknesses
in the underlying block cipher - weaknesses that may not necessarily
be
a concern when using the cipher in its more normal modes - and that
some
of them have been broken).
Hope this de-fuzzifies things a bit :-)
Paul(o)
--
Paul Onions [EMAIL PROTECTED]
PGP 2.6.3 key available
D704688BEFBF2D5D 546BC1D603E2A8E0
--
SCOTT19U.ZIP NO
