Cryptography-Digest Digest #664
Cryptography-Digest Digest #664, Volume #13 Fri, 9 Feb 01 17:13:00 EST
Contents:
Re: Factoring (and not the Philippino :) (Tom St Denis)
Re: Different cipher type ("Paul Pires")
Re: Mod function (Jerry Coffin)
Re: Different cipher type ("Paul Pires")
Re: relative key strength private vs public key (Steve Portly)
Re: relative key strength private vs public key (Thomas Kellar)
Re: Factoring (and not the Philippino :) (DJohn37050)
Re: Factoring (and not the Philippino :) (DJohn37050)
Re: Different cipher type ("Douglas A. Gwyn")
Re: Different cipher type ("Paul Pires")
Re: relative key strength private vs public key ("Douglas A. Gwyn")
Re: Encrypting Predictable Files ("Joseph Ashwood")
Re: Factoring (and not the Philippino :) (John Savard)
Re: relative key strength private vs public key ("Joseph Ashwood")
Re: Factoring (and not the Philippino :) ("Douglas A. Gwyn")
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Factoring (and not the Philippino :)
Date: Fri, 09 Feb 2001 18:58:17 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> DJohn37050 wrote:
> > if e = 3 then p (and q) = 2 mod 3 which gives more info about the values
>
> I have some general thoughts about potential RSA cracking:
> (1) N is computed from p and q, e and d are computed via z. It is
> often said that cracking an RSA encryption is equivalent to factoring
> N, but in practice one is faced with a known (N,e) and all that is
> needed for a crack is *some* d' (not necessarily the d maintained
> as a secret by the sender) that has the relevant inverse property,
> not p and q. Is it a theorem that knowing (N,e,d) allows a fast
> recovery of p and q? If not, then the notion that cracking RSA is as
> hard as factoring needs to be rethought.
The problem is while there are other 'd' that will decrypt JUST the same as
another, they are actually multiples of lcm(p-1,q-1). I.e 3m mod m = 0 just
like m mod m = 0. Thus 3^(n-1) mod n = 1 just like 3^3(n-1) mod n = 1.
Tom
Sent via Deja.com
http://www.deja.com/
--
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Different cipher type
Date: Fri, 9 Feb 2001 11:21:55 -0800
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Michael Brown wrote:
> > "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote ...
> > > Before spending much more time in this direction, read what Knuth
> > > had to say about his youthful attempt at a "super-random" generator
> > > (the Art of Computer Programming, Vol. 2: Seminumerical Algorithms).
> > Unfortunately, I can't get hold of this book (don't have it and nor do local
> > bookstores). Could you tell me what he had to say?
>
> It ought to be in any reasonable computer science library.
>
> Basically, he described an algorithm that tried to combine
> "at random" several methods of pseudorandom generation,
> with the idea that the result would be more random than the
> individual methods. When he actually implemented it, right
> away he found that it tended to get stuck in very short
> cycles. The moral was, methods of generating random numbers
> should not be designed at random.. Half of the book is
> concerned with a careful investigation of pseudorandom number
> generation.
Isn't this implicit in the context of working with a deterministic process?
There is a tension between mutually exclusive goals. Decouple the behavior
of the machine from the content of it's state enough that it is not predictable
but don't loose the richness of the hard won complexity of how the state
evolves. That probably doesn't make a lot of sense.
I guess I'm trying to describe an impression I have of how this works. To me,
It seems like the difficulty and art involved is in compromising and
complementing. Absolutely treating any routine to produce a desired effect
is likely to fail as this focus will result in the exposure of another problem.
Often, you hear people pound on the basics of needing number theory
knowledge and an understanding of cryptanalysis to design good ciphers
but an obvious point is missed. You need to be a good designer (in general)
also. In Mechanical Engineering, there is a distinction between Designers,
Engineers, Design Engineers and Proffesors. Maybe not at the University
level but definately within the trade. Different skill sets and focus. The
problem with this being such a new and specialized (and generally secretive)
feild is that we hear from the professors (No slight intended) often but don't
hear the w
Cryptography-Digest Digest #664
Cryptography-Digest Digest #664, Volume #12 Tue, 12 Sep 00 18:13:01 EDT
Contents:
Re: sac fullfilling decorelated functions (Tom St Denis)
Re: nice simple function (Tom St Denis)
Re: Steganography and secret sorting ("Douglas A. Gwyn")
Re: Need Tiger hash results for sample test data ([EMAIL PROTECTED])
Re: nice simple function (Tom St Denis)
Re: Intel's 1.13 MHZ chip ([EMAIL PROTECTED])
Re: Steganography and secret sorting (Matthew Skala)
Re: Weaknesses in this algorithm? (ArchimeDES)
search for better serpent sboxes (Tom St Denis)
Re: nice simple function (Simon Johnson)
Re: search for better serpent sboxes (Simon Johnson)
Re: Problem with Tiger hash algorithm and binary files (Konrad Podloucky)
Re: Known Plain Text Attack (Terry Ritter)
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sac fullfilling decorelated functions
Date: Tue, 12 Sep 2000 20:07:13 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> >
> > Let's take F(x) = a.x + b in GF(2)^32, now we want to know for any
> > multiple of 'a' in the same field what is the prob of at laest 16
bits
> > being set... so I take out some new finite I learnt and plug in (32
> > choose 16)/2^32 = 2^-2.837. This means about 1 in 6 will be SAC
> > fullfilling functions.
> >
> > Over the entire multiplcation we find 32/6 ~ 5.3 which means of the
32
> > multiples of 'a' only 5 are sac fullfilling. If 'a' is random there
> > distribution should be random (?). Now consider the lower bits,
such
> > as with only four bits set. We find them with a prob of 2^-16.865
much
> > less then with 16 bits.
> >
> > In any GF multiply the chances of any being of only four bits is
about
> > 2^-11 or 1 in 2048. This means that GF multiplication is a closely-
sac-
> > like function most of the time, and for a fraction of the time not.
> >
> > Can this be used to extract information from the function in those
> > specific cases (extreme cases?)
>
> F is linear. That's a much bigger problem :-)
Actually in Vaudenays paper if 'a,b' is random the function is immune
to linear cryptanalysis.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: nice simple function
Date: Tue, 12 Sep 2000 20:09:03 GMT
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
> Tom St Denis wrote:
> > f''(x) = f'(x ++ f(x)) where '++' represents modular integer
addition.
> > We now get f''(x) = f'(x ++ (a.x + b)) = c.(x ++ (a.x + b)) + d =
c.x
> > ++ c.(a.x + b) + d = c.x ++ (c.a.x + c.b) + d
> >
> > From what I can tell c.x cannot be grouped with c.a.x, which means
we
> > have an output that is a function of 'c' and 'a'. Also that c.b
cannot
> > be grouped with 'd', but since they are not a function of the input
can
> > we let 'b' be zero and just have f''(x) = (c.x ++ c.a.x) + d
> >
> > Which leads me to f''(x) = (a.x ++ b.x) + c as a new decorrelated
> > function. (Assuming a, b != 0).
> >
> > Am I nuts or what? Please comment :-)
>
> Plot it and see. Try 4 bits, so you have 4*4*4*4 possible pairs ( a
nice
> round number!) for each of a, b, c and x. What is the distribution of
> f''(x) as a function of a, c and x. I'm assuming the modulus is 2^4
as
> well, but you could really have fun by changing that :-)
The modulus is a degree 5 primitive polynomial in GF(2), or just the
integer 17 and use 1-16 as elements.
I will play around with it.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
--
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Steganography and secret sorting
Date: Tue, 12 Sep 2000 19:40:53 GMT
Mok-Kong Shen wrote:
> Sorry, I am not yet able to understand. Could you explain
> with a database of, say, 5 or 10 entries? Do you assume
> that the same database (without permutation) is available
> to both partners? Thanks.
The hard part is encoding the hidden message in terms of
a permutation. Supposing that to have been done, so the
permuted order for the coded message is 4,1,5,3,2 then
he transmitted database might be
Texas
Alaska
Vermont
Ohio
Wyoming
which when sorted (on the final letter in this example) is
Alaska
Wyoming
Ohio
Texas
Vermont
The reordering from the sorted database to the transmitted
one is readily found to be 4,1,5,3,2 which recovers the
coded message. Then whatever coding was ap
Cryptography-Digest Digest #664
Cryptography-Digest Digest #664, Volume #11 Sat, 29 Apr 00 19:13:01 EDT
Contents:
Re: sboxes for the bored... (Terry Ritter)
Re: factor large composite (Jerry Coffin)
Re: sboxes for the bored... (Tom St Denis)
Re: sboxes for the bored... (Tom St Denis)
How safe am I using a subset of the bytes returned by SHA-1? (Mark Thomson)
Re: How safe am I using a subset of the bytes returned by SHA-1? (Tom St Denis)
Re: A naive question (Bryan Olson)
Re: U-571 movie (OT) (Tom St Denis)
the security of scramdisk (EP847)
Re: Biometrics and public/private key encryption (Diet NSA)
Re: Help: encrypting bit fields (Francois Grieu)
Re: Intel drops serial number (Roger)
Re: U-571 movie (Diet NSA)
Re: Magnetic Remenance on hard drives. ("Trevor L. Jackson, III")
Re: new Echelon article (Diet NSA)
Re: U-571 movie (OT) ("Stou Sandalski")
Re: Janet and John learn about bits (was Re: Problems with OAP-L3) (Richard
Heathfield)
What are SBoxes? ("Monolo")
Re: the security of scramdisk (Ron Yakmile)
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: sboxes for the bored...
Date: Sat, 29 Apr 2000 20:27:23 GMT
On Sat, 29 Apr 2000 10:29:05 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> On Sat, 29 Apr 2000 00:05:55 GMT, in <[EMAIL PROTECTED]>, in
>> sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>>
>> >Terry Ritter wrote:
>> >> Measuring Boolean function nonlinearity is well-known technology.
>> >
>> >However, there are apparently different measures of nonlinearity;
>>
>> Yes, of course there would be different measures, in the same sense as
>> there are many different forms of linearity.
>>
>> >are they strictly equivalent?
>>
>> Within the context of Boolean functions (that is, n-bit to 1-bit
>> lookup tables), such functions are likely equivalent. The extension
>> to n-bit to m-bit tables, in which we measure each bit-column
>> independently, seems fairly common, if that is what we want to do.
>> Now, we might well *want* to do something else in which the sequences
>> are not measured independently, but I'm unaware of a useful
>> cryptographic measure for anything like that.
>
>Well meseasuring n by 1 sbox non-linearnity is not what I am trying todo
>here. I implemented a WT transform that goes thru all possible inputs
>and outputs. Could you just look at my code to see I implemented the WT
>properly please?
My first instinct is to say: "NO! Form some test vectors and test
your work and they you will know, and also then you can fix it to make
it work right if it doesn't."
I *can't* just *look* at code and see if it is right; few people can.
To see if code is right I have to *implement* the code, and the test
vectors, and see if the code does what it is supposed to do. I HAVE
ALREADY DONE THAT FOR MY CODE! And that code, at least, is in the
JavaScript page. Just view the source!
All that said, I would have looked at your code had I known were it
was. There is a reason URL's appear in newsgroup articles! I looked
back at your 3 or 4 previous contributions to this discussion, and saw
my URL's repeated, but nothing from you. So WHAT CODE?
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Sat, 29 Apr 2000 14:42:31 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Wasn't thinking of NFS. Simple trial and error division on assigned
> blocks of divisors to prevent duplication of effort. Nearly no chance
> of success, but what the hell. You are using other people's computers
> to do the work. And a nice payoff if you get lucky, and no real cost
> if you don't. Sort of like getting a free lotto ticket.
This isn't reasonable either. If you're going to try to distribute a
factoring job widely, it looks to me like the elliptical curve method
is what you really want to use. Even when you run it on a single
machine, ECM is still basically executed as a large number of pieces,
each of whihc is basically independent from the others. Eventually,
one of them turns up an answer.
If you're working on a number large enough that NFS is difficult to
contemplate, "eventually" will be a LONG time, but at least dividing
up the work to make the attempt is relatively easy.
--
Later,
Jerry.
The universe is a figment of its own imagination.
-
Cryptography-Digest Digest #664
Cryptography-Digest Digest #664, Volume #10 Thu, 2 Dec 99 12:13:01 EST
Contents:
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Hey, NSA! Venona html errors! ("John K. Taber")
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
Re: been a while since I used pgp (Johnny Bravo)
Re: Encrypting short blocks (Eric Lee Green)
Re: Pleasantville: civilty under duress ([EMAIL PROTECTED])
Re: The $10,000.00 contesta (Bruce Schneier)
Re: Elliptic Curve Public-Key Cryptography (Bruce Schneier)
Re: Elliptic Curve Public-Key Cryptography (DJohn37050)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: Elliptic Curve Public-Key Cryptography (David Wagner)
Re: Random Noise Encryption Buffs (Look Here) (Guy Macon)
Re: Noise Encryption ("Tim Wood")
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 02 Dec 1999 15:10:00 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Brian Chase wrote:
>> I think what I'm finding most disturbing, if not just outright disgusting,
>> is how quickly disregarded are Scott's challenges to the conventions of
>> the cryptology community. Sure he's an asshole, but as a community is it
>> not true that we don't conclusively know how secure the contemporary
>> algorithms are?
>
>Neither does D.Scott! The main problem with his arguments is that
>he asserts weaknesses in everybody's encryption schemes except his,
>but doesn't *demonstrate* the weaknesses. When he claims, for
>example, that CBC itself creates exploitable weaknesses, yet there
>happen to be solid mathematical papers demonstrating that CBC used
>with a *strong* block cipher is not substantially weaker than the
>block cipher by itself, it is incumbent on *him* to prove his claim,
Again I see the assholes misquote me. I never said that
CBC makes a cipher weaker. What I have said is that the diffusion
is not more than 2 blocks. So that an attacler using a small number of
blocks would never have to look at the whole file. Since all the 3 letter
modes that you dumb people ever use really add very little strength
the the cipher. I even give examples that show the information is not
distributed through the whole file. Most are to stupid to understand this
fact. Of those smart enough to understand most don't seem to care.
In the three letter modes when some one does even a partical plain
text attack you can get the input output pairs to the underlying
blokc cipher. These may or may not be of use to the person breaking
the cipher. With 3 rounds of "wrapped PCBC" this information is not easily
available. So it can't be used. One is forced to examine the encryption
as a whole. Something that the nomral block chaining methods have
gone out of there way to avoid. To me the reason is obvious.
The NSA has done a good job of keeping people stupid about using
chaining to secure a ciper.
>or at least to exhibit an error in the previous work that proved the
>opposite. That's not only standard professional practice, it's
>plain common sense. Since he doesn't make a convincing case,
>preferring to curse and challenge the integrity of anyone who
>disagrees with him, it is not surprising that he is being almost
>entirely ignored by the professional community.
I guess I just like to call a spade a spade big fucking deal.
you can call it a shovel.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
--
From: "John K. Taber" <[EMAIL PROTECTED]>
Subject: Hey, NSA! Venona html errors!
Date: Thu, 2 Dec 1999 08:18:50 -0600
You have duplicate gif names on the Aug 43 page, for the 12th and
19th. Are the duplicates supposed to be, or is this an error?
Also, there are apparent html errors on the Jul 43 page that
cause non-selected hyperlinks to appear as if selected.
Finally, you really need a webmaster email address for queries
like this. How about it?
--
Consuming is dirty business, but somebody has to do it. Robert McTeer
--
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curve Public-Key Cry
Cryptography-Digest Digest #664
Cryptography-Digest Digest #664, Volume #9Sat, 5 Jun 99 13:13:03 EDT
Contents:
Re: New Computer & Printer for Dave Scott (Illia Kuriakin)
Function Feedback Registers ([EMAIL PROTECTED])
Re: Viability of encrypted flash cards? ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY ([EMAIL PROTECTED])
Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
([EMAIL PROTECTED])
Re: The BRUCE SCHNEIER Tirade ([EMAIL PROTECTED])
Re: DES Effective Security Q ("karl malbrain")
Re: Challenge to SCOTT19U.ZIP_GUY (Frank Gifford)
Re: OTP Problems ([EMAIL PROTECTED])
Re: New Computer & Printer for Dave Scott ([EMAIL PROTECTED])
From: Illia Kuriakin <[EMAIL PROTECTED]>
Subject: Re: New Computer & Printer for Dave Scott
Date: Sat, 05 Jun 1999 06:57:59 -1000
I will donate $100 for David Scott's new computer.
We can load it with a C compiler of Our choice,
and a spell checker.
If we get 9 donors of $100 each, we can purchase it
and ship it to David as a completed package. I am serious,
please sign up today.
--
From: [EMAIL PROTECTED]
Subject: Function Feedback Registers
Date: Sat, 05 Jun 1999 13:45:46 GMT
I was wondering if there are references to FFR (Function Feedback
Registers). My example (in C below) works with four byte size
registers, but unfortunetaly the cycle length is only 2^31.98 so it's
not perfect. Basically the register works like a LFSR with the taps
but when you shift the cells (they are not nesscessary bits or bytes)
they pass thru a function before resting. For example the one below
would be
Taps -> f1(x) -> A -> f2(x) -> B -> f3(x) - > C -> f4(x) -> D -> output
(Tapping on A and B)
unsigned char func[4][256], regis[4];
unsigned char clock(void)
{
unsigned char temp, o;
temp = regis[3] ^ regis[0];
o = regis[0];
regis[0] = func[0][(unsigned)regis[1]];
regis[1] = func[1][(unsigned)regis[2]];
regis[2] = func[2][(unsigned)regis[3]];
regis[3] = func[3][(unsigned)temp];
return o;
}
It seems to me that this would be non linear. And as long as the
tables are private it may have some cryptographic significance
(Although the cycle is not maximal length).
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
--
From: [EMAIL PROTECTED]
Crossposted-To: alt.security,talk.politics.crypto
Subject: Re: Viability of encrypted flash cards?
Date: Sat, 05 Jun 1999 14:55:42 GMT
On Thu, 03 Jun 1999 22:37:39 GMT, "Cor!"
<[EMAIL PROTECTED]>
wrote:
>>Do you think PGP is used by criminals more than anyone
>>else?
>I don't know; I never thought about it before. Are there any statistics
>on this?
If there were statistics as to the type of messages that PGP is used
on, then that would imply that someone can tell.
I hope not.
--
Date: Fri, 04 Jun 1999 23:52:27 -0400
From: [EMAIL PROTECTED]
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Tim Redburn wrote:
>
> On Fri, 04 Jun 1999 20:24:05 GMT, [EMAIL PROTECTED]
> (SCOTT19U.ZIP_GUY) wrote:
>
> >
> > I have worked on many aircraft simulations and OFP;s one of the main
> >problems that seems to occur over and over is that other people keep
> >missing the obvious errors in the code becasue most people inheirently
> >put faith on the comments and this leads to major maistakes that take
> >years to find and fix.
>
> Quite the opposite. Comments tell you what the programmer intended.
> It is then easier then to verify that the code actually works
> as intended. If you don't know what the code was meant to do, how can
> you debug it ?
Actually it's harder than that. Comments often tell you what the
_original_ programmer _originally_ intended. The secret to good writing
(of any kind) is rewriting. Rewriting implies that the intentions of
the author evolve during the process. Thus the final intentions of the
author(s) may be arbitrarily far from the original intentions.
A truism of software maintenance (which is mostly software analysis) is
that the value of comments is often negative. More often than not. The
cost of persuing a false trail based on the comments is high. It can
pollute your concept pool long after you've learned better (holographic
memory effects I suppose).
ThHis explains one of the first rules of maintenance. Delete the
comments, then study
