Cryptography-Digest Digest #121

2001-04-10 Thread Digestifier

Cryptography-Digest Digest #121, Volume #14  Tue, 10 Apr 01 18:13:00 EDT

Contents:
  Re: Dynamic Substitution Question (Mok-Kong Shen)
  SHA256 VB Implementation ("Phil Fresle")
  Re: Dynamic Substitution Question (newbie)
  Re: Would dictionary-based data compression violate DynSub? (David Formosa (aka ? 
the Platypus))
  Re: Would dictionary-based data compression violate DynSub? (Mok-Kong Shen)
  Bleichenbacher Attack on DSA ("vert")
  Re: Delta patching of encrypted data (those who know me have no need of my name)
  Re: Steganography with natural texts (Joe H Acker)
  Re: Steganography with natural texts (John Bailey)
  Re: Current best complexity for factoring? (=?iso-8859-1?Q?Claus_N=E4veke?=)
  Frobenius map over q-adic integers (Ian Goldberg)
  Re: Is this a block cipher? (John Savard)
  2001 USENIX Annual Technical Conference (Becca Sibrack)
  AES Inverse trick (alex)



From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Dynamic Substitution Question
Date: Tue, 10 Apr 2001 21:14:40 +0200



John Savard wrote:
 

 So I don't think anything involving a "virtual" table - unless the
 virtual table is a subterfuge for something that can be achieved by
 manipulating individual entries - can be considered novel. And if you
 manipulate individual entries directly, the normal result is that you
 can reach any state of the table - this is nowhere said in his patent,
 but it is a useful litmus test to determine if individual entries are
 really involved or not.

If the table is a substitution table (each column being
a permutation), dynamic change of the content of the
table is presumably the proper scope of DS. It could not
cover cases of other 'kinds' of tables (also dynamically 
changed) and cases where there is no table at all, e.g. 
xoring or adding two byte streams together (modulo 2^8) 
to obtain a new stream or adding the outputs of a number
of PRNGs to get a combined stream (device of Wichmann
and Hill), which the text of the patent however seems 
to claim to be within its scope.

M. K. Shen

--

From: "Phil Fresle" [EMAIL PROTECTED]
Subject: SHA256 VB Implementation
Date: Tue, 10 Apr 2001 20:36:06 +0100
Reply-To: "Phil Fresle" [EMAIL PROTECTED]

I have uploaded VB and VBScript implementations of SHA256 onto my web site
http://www.frez.co.uk




--

From: newbie [EMAIL PROTECTED]
Subject: Re: Dynamic Substitution Question
Date: Tue, 10 Apr 2001 15:33:20 -0300

It is not a good solution Dynamic Substitution as presented by Ritter.
It contains a very big hole.
You have just to analyze it carefully.
Using the combiner DS, reveal the sequence of the keystream.
Just try to analyze it before talking about claiming.
Claiming of what?
Something completely wrong.

 

Mok-Kong Shen wrote:
 
 John Savard wrote:
 
 
  So I don't think anything involving a "virtual" table - unless the
  virtual table is a subterfuge for something that can be achieved by
  manipulating individual entries - can be considered novel. And if you
  manipulate individual entries directly, the normal result is that you
  can reach any state of the table - this is nowhere said in his patent,
  but it is a useful litmus test to determine if individual entries are
  really involved or not.
 
 If the table is a substitution table (each column being
 a permutation), dynamic change of the content of the
 table is presumably the proper scope of DS. It could not
 cover cases of other 'kinds' of tables (also dynamically
 changed) and cases where there is no table at all, e.g.
 xoring or adding two byte streams together (modulo 2^8)
 to obtain a new stream or adding the outputs of a number
 of PRNGs to get a combined stream (device of Wichmann
 and Hill), which the text of the patent however seems
 to claim to be within its scope.
 
 M. K. Shen

--

From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Would dictionary-based data compression violate DynSub?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 10 Apr 2001 19:36:05 GMT

On Mon, 09 Apr 2001 12:08:45 +0200, Mok-Kong Shen
[EMAIL PROTECTED] wrote:
 
 "David Formosa (aka ? the Platypus)" wrote:
[...]
 Ok that helps.
 
 For your information, Algorithm M is deterministic,
 so it can be undone/reversed, if wanted.

Just because it is deterministic doesn't mean it can be undone.  
x^y mod p is almost impossable to undo for the correct x and p.

-- 
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.

--

From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Would dictionary-based data compression violate DynSub?
Date: Tue, 10 Apr 2001 22:04:37 +0200



"David Formosa (aka ? the Platypus)" schrieb:
 
 Mok-Kong Shen[EMAIL PROTECTE

Cryptography-Digest Digest #121

2000-11-08 Thread Digestifier

Cryptography-Digest Digest #121, Volume #13   Wed, 8 Nov 00 12:13:01 EST

Contents:
  Re: "Software TEMPEST" explained (Mack)
  Re: "Software TEMPEST" explained (Mack)
  Re: Random Number Newsgroup (Mack)
  Re: Hardware RNGs (Alan Rouse)
  Re: hardware RNG's (Alan Rouse)
  Re: Hardware RNGs (Mack)
  Re: Randomness from key presses and other user interaction (Mack)
  Re: MORE THAN FULLY BIJECTIVE ! (SCOTT19U.ZIP_GUY)
  Going to NESSIE (Mack)
  Re: algorithms before 1939 (Erik Runeson)
  Re: Randomness from key presses and other user interaction ("Frog2000")
  Re: Updated XOR Software Utility (freeware) Version 1.1 from  (Scott Craver)
  Re: Updated XOR Software Utility (freeware) Version 1.1 from Ciphile   (Scott Craver)
  Re: hacker...beware ("jdm")
  Re: Purported "new" BXA Encryption software export restrictions ("CMan")



From: [EMAIL PROTECTED] (Mack)
Subject: Re: "Software TEMPEST" explained
Date: 08 Nov 2000 13:58:09 GMT

On Thu, 19 Oct 2000 13:09:05 GMT, [EMAIL PROTECTED] (John
Savard) wrote:

On Wed, 18 Oct 2000 12:13:52 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:

I've revised the page since this posting to point out that I'm
discussing a very simplistic scheme, that falls far short of the
sophistication of the measures discussed in the paper by Markus Kuhn
and Ross Anderson.

Having added a second illustration of my simplistic scheme, I'm now
starting to wonder if it has been actually used, as I vaguely recall
seeing a computer display that looked sort of like it, on some TV
science-fiction or gadget spy show.

John Savard

   John,

   Went there, but nothing "Tempest" jumped out at me though
much worthy there as well. Did  I miss it?

   Andrew

http://home.ecn.ab.ca/~jsavard/crypto.htm








Hey ... It is gone ...
It was there ... where did it go?


Mack
Remove njunk123 from name to reply by e-mail

--

From: [EMAIL PROTECTED] (Mack)
Subject: Re: "Software TEMPEST" explained
Date: 08 Nov 2000 14:02:14 GMT

On Thu, 19 Oct 2000 13:09:05 GMT, [EMAIL PROTECTED] (John
Savard) wrote:

On Wed, 18 Oct 2000 12:13:52 GMT, [EMAIL PROTECTED]
(John Savard) wrote, in part:

I've revised the page since this posting to point out that I'm
discussing a very simplistic scheme, that falls far short of the
sophistication of the measures discussed in the paper by Markus Kuhn
and Ross Anderson.

Having added a second illustration of my simplistic scheme, I'm now
starting to wonder if it has been actually used, as I vaguely recall
seeing a computer display that looked sort of like it, on some TV
science-fiction or gadget spy show.

John Savard

   John,

   Went there, but nothing "Tempest" jumped out at me though
much worthy there as well. Did  I miss it?

   Andrew

http://home.ecn.ab.ca/~jsavard/crypto.htm




found it

It is listed as Hardware Security
which is kind of misleading
for software tempest protection
the full link is

http://home.ecn.ab.ca/~jsavard/crypto/mi0606.htm


Mack
Remove njunk123 from name to reply by e-mail

--

From: [EMAIL PROTECTED] (Mack)
Subject: Re: Random Number Newsgroup
Date: 08 Nov 2000 14:03:56 GMT

Mok-Kong Shen [EMAIL PROTECTED] wrote:
 Does anyone know how the new random number newsgroup is coming along?  I
 haven't heard anything since I (and other voters) were notified that the
 vote was to establish a newsgroup dealing with random numbers.

 We have since quite a time sci.crypt.random-numbers.

It passed 134:12 on 29 March 2000, the control message was sent on 3
Apr 2000. I wouldn't feel left out if you don't get it, however, it
never showed up here, either.

You should be able to have your isp add it painlessly though, by
pointing out that it passed the vote and is in the isc active file.

-- 
Matt Gauthier [EMAIL PROTECTED]



deja.com also carries and archives it if you want to see
the old postings


Mack
Remove njunk123 from name to reply by e-mail

--

From: Alan Rouse [EMAIL PROTECTED]
Subject: Re: Hardware RNGs
Date: Wed, 08 Nov 2000 13:56:33 GMT

Benjamin Goldberg wrote:

 This seems to be a very stupid thing to do;  It would be far more
 intelligent to calculate the amount of bias...

So sorry to have disappointed you with my stupidity.  I was merely
illustrating a point, not proposing a system design.

There are a lot of people who think that if you take something with
limited randomness(like a password, or a few bytes of digitized sound)
and generate a 160-bit message digest from it, you effectively have 160
bits of cryptographic security.  I am not one of those people, and
apparently you are not either.


Sent via Deja.com http://www.deja.com/
Before you buy.

--

From: Alan Rouse [EMAIL PROTECTED]
Subject: Re: hardware 

Cryptography-Digest Digest #121

2000-06-28 Thread Digestifier

Cryptography-Digest Digest #121, Volume #12  Wed, 28 Jun 00 03:13:01 EDT

Contents:
  Re: Certificate authorities (CAs) - how do they become trusted  (jungle)
  Re: simple crypting (jungle)
  Comment/Analysis requested Password to RawBinarykey method... (Jay Summet)
  Re: Variability of chaining modes of block ciphers ("Scott Fluhrer")
  Re: scramdisk and e4m security problem? (Mack)
  Does anyone have code for generating primitive polynomials? (Mack)
  Re: Idea or 3DES (Jim Gillogly)
  Bug in reference implementation (Runu Knips)



From: jungle [EMAIL PROTECTED]
Subject: Re: Certificate authorities (CAs) - how do they become trusted 
Date: Wed, 28 Jun 2000 01:10:34 -0400

[EMAIL PROTECTED] wrote:
 In doing a bit of research on internet security I naturally came
 across "Certificate authorities (CAs)" (ie: Verisign, twaite, etc) ...
 can anyone tell me (or give me a URL) from where these companies get
 *their* certification - who says they are 'trusted' 

themselves ...

trusted ? no way ...
the trust warranty is about a nickel ...



--

From: jungle [EMAIL PROTECTED]
Subject: Re: simple crypting
Date: Wed, 28 Jun 2000 01:16:14 -0400

for fun ? no ...
for profit ? maybe ...
for fame ? could be ...

start by offering, say $10,000.00, you may be lucky ...

[EMAIL PROTECTED] wrote:
 
 if i post e crypted message here...
 is there anyone here who could decrypt it?



--

From: Jay Summet [EMAIL PROTECTED]
Subject: Comment/Analysis requested Password to RawBinarykey method...
Date: Tue, 27 Jun 2000 22:17:38 -0700

Hello,

I have implemented a (JAVA) class that is designed to store a String using
Blowfish and DESede (TripleDES) in combination. (Xor message with random
pad, encrypt pad with one, encrypt messageXORpad with other, must decrypt
both to retrieve message... [ciphertext is double size of message] )

This is somewhat straightforward. However, I am generating a key based
upon a user inputed pass phrase. I want a different (binary/raw key) for
each algorithm (2 different keys from the same passphrase).

So, I built my own String - raw binary array of bits/bytes method, using
hash functions (MD5 and SHA, one for each cipher). A link to direct source
code is provided at end of post, here is the overview.

We take the passphrase, and give it to the hash (say MD5). We get a hash
value out. We use the first byte of the hash value to index into the hash
value ("randomly") and use that byte as the first byte of our key.

To generate the next byte of our key, we make a new MD5 hash, and as input
give it:
1. the key so far (ie, 1 byte first time, 2 bytes second time, etc)
2. The original passphrase.
3. Another byte selected from the hash (indexed by the second byte of the
hash this time, so it may be different from the last byte selected for the
key, or it may be the same...)

We repeat this until the bytes of the key are filled up (24 for DESede, 56
for blowfish). (one version uses MD5, one version uses SHA1)

*I* think that this is a secure way to convert a user supplied passphrase
into a "good" (ie, random looking) key.

Am I right?

Source code is at:
http://www.summet.com/jdiary/EncryptedStringStorage.java

The methods to look at are: generateBlowfishKey and generateTripleDESKey


I'm not as worried about the actual encryption and decryption steps, but
if you want to look at them and see if I'm doing anything stupid there I
certainly wouldn't mind finding out about it!

Thanks,
Jay Summet


--

From: "Scott Fluhrer" [EMAIL PROTECTED]
Subject: Re: Variability of chaining modes of block ciphers
Date: Tue, 27 Jun 2000 22:12:57 -0700


Mok-Kong Shen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...


 Mark Wooding wrote:

  Mok-Kong Shen [EMAIL PROTECTED] wrote:
   Mark Wooding wrote:
Mok-Kong Shen [EMAIL PROTECTED] wrote:
 Scott Fluhrer wrote:
  
   [snip]
  
 You are distorting the discussion context. We are discussing the
 possibilities to obtain some improvements upon a given cipher with
 some chaining modes, not discussing using two or more ciphers.
   
I think that Scott is trying to say that if you're not happy with
your
cipher's security, you're best off preprocessing with another cipher
rather than playing with fancy chaining modes.
  
   That's right. Hence my answer to him.
 
  But your answer doesn't address his point.
 
  The point is that you're using the wrong fix.  The right fix is a good
  cipher.  Use one.

 You snipped out what Scott Fluhrer worte and then provided the wrong
 argument. Here is what he wrote before my sentences quoted above:

The argument appears to have wandered over to what I meant.  Let me settle
the argument: I did not initially mean anything nearly as intellegent as
what Mr. Wooding ascribed to me (that is,

Cryptography-Digest Digest #121

2000-02-14 Thread Digestifier

Cryptography-Digest Digest #121, Volume #11  Mon, 14 Feb 00 15:13:02 EST

Contents:
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) (Guy Macon)
  Re: Predicting the next random number (Guy Macon)
  Re: Large Floating Point Library? ("Trevor Jackson, III")
  Re: help DES encryption (John Myre)
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) ([EMAIL PROTECTED])
  Re: Does the NSA have ALL Possible PGP keys? ("Al Manint")
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) ("Dave VanHorn")
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) (Bob Silverman)
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) ([EMAIL PROTECTED])
  Re: Which compression is best? (Toby Kelsey)
  Re: Guaranteed Public Key Exchanges (Mike Rosing)
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) (Mike Andrews)
  Re: Large Floating Point Library? (Mike Rosing)
  Re: Does the NSA have ALL Possible PGP keys? (James Felling)
  Re: New standart for encryption software. (Albert P. Belle Isle)
  Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
  Re: Quastion about RSA function.  Help (Mike Rosing)
  Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
  Re: Which compression is best? (Tim Tyler)
  Re: UK publishes 'impossible' decryption law (zapzing)
  Re: Does the NSA have ALL Possible PGP keys? (Jim)



From: [EMAIL PROTECTED] (Guy Macon)
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Funniest thing I've seen in ages - RSA.COM hacked :)
Date: 14 Feb 2000 11:16:43 EST

In article 889455$ivh$[EMAIL PROTECTED], [EMAIL PROTECTED] (Bob Silverman) wrote:

In article 888hp2$6sp$[EMAIL PROTECTED],

 I wonder how long it'll take them to notice...Hhhm, would you
 trust RSA with your data security now? ;)

Will anyone trust YOU now???

Our website address is www.rsasecurity.com   and has been so
for some time. www.rsa.com  is no longer a valid URL.


Is this what I can expect if I become an RSA customer?
No admisssion of fault and lame attempts to cover up
security breaches?  You should put a full disclosure about
exactly how you screwed up on your website and you should
stop trying to blow smoke up my ass about who owns www.rsa.com.

BTW, I found the link "RSA Laboratories Unveils Innovative
Countermeasure To Recent Denial of Service Hacker Attacks"
to be particularly clueless.  Yahoo and Ebay can already
set their servers to ignore traffic from the attacking sites
without RSA's "Innovative" help.  The problem is that
rejecting the traffic uses up resources.  You folks are
addressing the wrong problem.

Are you really a mole who is trying to drive customers to PGP?


--

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Predicting the next random number
Date: 14 Feb 2000 11:19:12 EST

In article [EMAIL PROTECTED], [EMAIL PROTECTED] 
(John Savard) wrote:

On Mon, 14 Feb 2000 08:16:39 GMT, [EMAIL PROTECTED] wrote, in part:

Hey, I was just curious, but if someone came up with a way to predict
the numbers from ANY pseudo random number generator, would the NSA
come and take them away for some reason that I can currently fathom???

They'd have to stand in line behind Las Vegas.

John Savard (teneerf -)
http://www.ecn.ab.ca/~jsavard/index.html

I was under the impression that Las Vegas never uses Pseudorandom.


--

Date: Mon, 14 Feb 2000 11:27:40 -0500
From: "Trevor Jackson, III" [EMAIL PROTECTED]
Subject: Re: Large Floating Point Library?

Clockwork wrote:

 There are numerous large integer libraries, but does anyone know of a large
 floating point library?

There are several packages that implement quad-precision floating point values.
Some use paired doubles and can represent numbers such as 1+1e-200 and others
simply provide a wider mantissa.

A search for "quad" should turn up several such libraries.



--

From: John Myre [EMAIL PROTECTED]
Subject: Re: help DES encryption
Date: Mon, 14 Feb 2000 09:33:57 -0700

"Douglas A. Gwyn" wrote:
 Paul Koning wrote:
  NIST publishes a book that spells out a detailed set of validation
  procedures, including some that will help isolate problems.
  It's NIST Special Publication 800-17, "Modes of Operation Validation
  System (MOVS): Requirements and Procedures".  ...
 
 Which unfortunately is not available in on-line format;
 it can be ordered in printed form.

What's wrong with 800-17.pdf at the same site as below?

 A similar document for 3DES *is* available on line:
 http://csrc.nist.gov/nistpubs/800-20.pdf

J.M.

--

From: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Funniest thing I've seen in ages - RSA.COM hacked :)
Date: Mon, 14 Feb 2000 16:39:48 GMT

Bob Silverman seems t

Cryptography-Digest Digest #121

1999-08-27 Thread Digestifier

Cryptography-Digest Digest #121, Volume #10  Fri, 27 Aug 99 14:13:02 EDT

Contents:
  Re: NEW THREAD on compression
  Re: (fwd)Factorization of RSA-155 (DJohn37050)
  Re: 512 bit number factored (DJohn37050)
  Re: 2 person data exchange - best method? (Anton Stiglic)
  Re: 512 bit number factored (Anton Stiglic)
  Re: 512 bit number factored (Jean-Jacques Quisquater)
  Re: CryptoAPI (Greg)
  Re: NEW THREAD on compression (SCOTT19U.ZIP_GUY)
  Re: 512 bit number factored (Boudewijn W. Ch. Visser)
  Re: Can americans export crypto when in another country? (SCOTT19U.ZIP_GUY)
  Re: receiving a piece of message (SCOTT19U.ZIP_GUY)
  RE: receiving a piece of message (SCOTT19U.ZIP_GUY)
  How to apply for security clearance? ([EMAIL PROTECTED])
  Re: 512 bit number factored (Paul Koning)
  Re: passphrases (Justin Scribner)
  Re: Where to find (SCOTT19U.ZIP_GUY)
  Re: Can americans export crypto when in another country? (John)
  Re: Can americans export crypto when in another country? (Medical Electronics Lab)
  Re: 512 bit number factored (David A Molnar)
  Re: Can americans export crypto when in another country? (John)
  Re: Can americans export crypto when in another country? (John)
  Re: Can americans export crypto when in another country? (wtshaw)
  Re: 512 bit number factored (Boudewijn W. Ch. Visser)
  Re: Key to Ciphertext Ratio's (wtshaw)
  Re: How to apply for security clearance? (Jean-Jacques Quisquater)



From: [EMAIL PROTECTED] ()
Subject: Re: NEW THREAD on compression
Date: 27 Aug 99 14:20:00 GMT

Mok-Kong Shen ([EMAIL PROTECTED]) wrote:
: You are considering using compression as sort of encryption. But
: I am adopting the (I suppose) more common view that compression and
: encryption are orthogonal. Compression helps the encryption but
: I assume that, once the analyst correctly decrypts by using the
: correct key, properly doing decompression is no problem for him.

Granting that last assumption, which _is_ a proper assumption, it still
makes it easier to find that correct key if there are _any_ biases in the
compressed text.

Compression is _not_ a secure form of encryption, but it can be tailored
to provide the maximum possible assistance to encryption by providing the
fewest possible identifiable plaintext characteristics for a
ciphertext-only attack to operate on. 

: Yes, this works if the sole purpose is compression/decompression. 
: But if this stuff is encrypted and decrypted back with a wrong key,
: you wouldn't have the proper length information. This, according
: to Mr. Scott's reasoning, is bad, because it immediately tells him
: that the key he has employed is wrong.

At least one has to go through the whole message, from start to finish, to
find that the wrongly deciphered message has ended in the middle of a
symbol.

But I'll think about it and see if I can do better.

John Savard

--

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: (fwd)Factorization of RSA-155
Date: 27 Aug 1999 15:20:26 GMT

There are also comments on factoring RSA 155 on www.certicom.com
Don Johnson

--

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: 512 bit number factored
Date: 27 Aug 1999 15:22:53 GMT

Also look at 
http://www.certicom.com/press/rsa-155.htm for more analysis of the results.
Don Johnson

--

From: Anton Stiglic [EMAIL PROTECTED]
Subject: Re: 2 person data exchange - best method?
Date: Fri, 27 Aug 1999 11:26:36 -0400


A pseudo random function generator PRFG.  Alice and Bob pick a
function f() from a PRFG, when they are seperated and want to
authenticate
themselves, say Alice picks a random value x, gives it to Bob and Bob
computes f(x) and gives this back to Alice.  Alice and Bob do this
several
times, to the point of view of Oscar, f(x) seems random.  And even if he

collects x1,f(x1),   x2,f(x2), ... xn, f(xn), this doesn't help him to
compute
f(x) from x (if x is different from x1, x2, .., xn), and doesn't help
him to
authenticat himself to Alice beacause Alice picks her x at random (doing

it a couple of times, you can get great probability that she doesn't
stumble
on an x that was already sent to Bob).
You could think of a man in the middle attack, where Oscar, wanting to
authenticat himself as Bob to Alice, gets the x from Alice and asks Bob
to compute the answer, but Bob should only answer questions if _he_ is
the initiator of the scheme. You should be carefull here. Anyways, it's
not
trivial, but I hope I have gave you some ideas for you to further
research
on

as


--

From: Anton Stiglic [EMAIL PROTECTED]
Subject: Re: 512 bit number factored
Date: Fri, 27 Aug 1999 11:42:23 -0400

DJohn37050 wrote:

 Also look at
 http://www.certicom.com/press/rsa-155.htm for more analysis of the results.
 Don Johnson

I guess you ment:


  http://www.certicom.com/press/RSA-155.htm

Cryptography-Digest Digest #121

1999-02-22 Thread Digestifier

Cryptography-Digest Digest #121, Volume #9   Mon, 22 Feb 99 13:13:02 EST

Contents:
  Re: Testing Algorithms (Patrick Juola)
  Crypt for FTP Protocol ([EMAIL PROTECTED])
  rfc1319 algorithm != reference impl.  (Adam Worrall)
  Re: Testing Algorithms ("Trevor Jackson, III")
  Re: Randomness of coin flips (R. Knauer)
  Re: Looking for proof on whitening (Jerry Leichter)
  Re: Testing Algorithms (Patrick Juola)
  Re: Randomness of coin flips (R. Knauer)
  IDEA test vectors? (Dominik Werder)
  Re: True Randomness (R. Knauer)



From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Testing Algorithms
Date: 22 Feb 1999 09:35:49 -0500

In article [EMAIL PROTECTED],
Trevor Jackson, III [EMAIL PROTECTED] wrote:
Coen Visser wrote:

 fungus [EMAIL PROTECTED] writes:
 Vegeta-the original Super Saia-jin wrote:

 [...]

  As far as security goes, key length helps, but it won't make it secure, I
  think that DES proves that, it's a joke, and a bad one at that.
 
 
 So you think a 256 bit key will eventually be brute forced?

 Why not? Who can look 50 years into the future or 100 years or 200 years?

You may be underestimating the steepness of exponentials.  2^256 is a fearsome
number.  Rather than envisioning a machine (or machines) doing trial
decryptions, try envisioning simply counting up to 2^256.

At forseeable PC speeds of around 1GHz (2^30) you'd need 2^226 machine-seconds.
If you envision machines a billion times faster you need 2^196 machine seconds.

On the other hand, Moore's Law has suggested that machine speed
doubles about ever eighteen months.  This means that a machine a billion
times faster (2^30) will only take about 45 years to develop.

A machine 2^200 times faster than current machines -- which *can* brute
force 56-bit keys, will require about 300 years to develop, according
to Moore's law.

Given that people have, for the past 20 years, routinely been claiming
that "Moore's Law cannot hold much longer due to fundamental physical
limitations," it's starting to look like betting that Moore's law
will NOT hold isn't a safe bet.

-kitten

--

From: [EMAIL PROTECTED]
Subject: Crypt for FTP Protocol
Date: Mon, 22 Feb 1999 14:13:01 GMT



My users have repeatedly asked if I could add crypt/cipher to my FTPD so I've
finally got around to looking at it ;)   So basically I've trying to find if
there is some easy to use crypt library that would do something usable in this
case.

I've looked at "ssh" ofcourse, and if you wanted to just crypt the
control-session it would be fairly straight-forward to tunnel it, but since
it is required to crypt the data-sessions as well it makes it more
complicated. (Far beyond your average user I suspect?)  Although ssh2 comes
with what looks like a library of sorts, ssh2's licence makes it pretty much
useless in that sense.  The "sftp" that comes with it breaks FTP-Protocols
too much to be really used (still basic ssh challange before it drops down
into FTP-style protocols).

The problem is, I'm rather a newbie to ciphers. I got the impression that
"ssh" uses RSA public-key to send across a session-key which is then used for
IDEA for  the remainer of the session.  Would this be sufficient?  Are there
better options?  PGP? (or is that just RSA again, showing my ignorance :) )

The idea is to add something "not too complex" - to make merging with existing
FTPD and FTP client code fairly straight forward.



Well, basically, any information to aid me and further my knowledge will be
appreciated :)

Lund




= Posted via Deja News, The Discussion Network 
http://www.dejanews.com/   Search, Read, Discuss, or Start Your Own

--

From: Adam Worrall [EMAIL PROTECTED]
Subject: rfc1319 algorithm != reference impl. 
Date: Mon, 22 Feb 1999 13:51:41 GMT

In section 3.2 of rfc1319 ('The MD2 Message Digest Algorithm'),
some pseudo-code for generating an initial checksum is given.
(Note that this checksum is appended to the data before the
 main message digest algorithm is brought to bear.)

In the middle of the loop (shown below), the pseudo-code in the
RFC shows a byte of the checksum being assigned a value from a
lookup table.

In the reference implmentation, supplied in the RFC itself, the
relevant code *xor's* the current value of the byte with the
value from the lookup table.

I've looked around and seen no mention of this, but it seems
pretty clear that the algorithm does not agree with the reference
implementation. Other implementations all follow the reference,
by the way ;)

The relevant excerpts are shown below; line 137 of the rfc
corresponds to line 186 of the C source code.

==={ rfc1319:~131=140 }===
131  /* Process each 16-word block. */
132  For i = 0 to N/16-1 do
133
134 /* Checksum block i. */
135