Cryptography-Digest Digest #715
Cryptography-Digest Digest #715, Volume #13 Mon, 19 Feb 01 12:13:01 EST
Contents:
Re: Big Numbers in C/C++ (Paul Schlyter)
RSA on FPGA ("ajd")
Steak (again) ("Henrick Hellström")
Re: "RSA vs. One-time-pad" or "the perfect enryption" ("Trevor L. Jackson, III")
Re: Fractal encryption? ("Trevor L. Jackson, III")
Re: Metallurgy and Cryptography ("Trevor L. Jackson, III")
Re: Ciphile Software: Why .EXE files so large (Richard Herring)
Re: Steganography with ASCII text files (Bram Labarque)
Is there an algorithm to sequentially enumerate all transcendental (jtnews)
Re: Is there an algorithm to sequentially enumerate all transcendental (Jan
Kristian Haugland)
Re: Is there an algorithm to sequentially enumerate all transcendental numbers?
(stanislav shalunov)
Re: Is there an algorithm to sequentially enumerate all transcendental (jtnews)
Re: Is there an algorithm to sequentially enumerate all transcendental (Jon and
Mary Frances Miller)
Re: Is there an algorithm to sequentially enumerate all transcendental numbers?
(David C. Ullrich)
Re: CipherText patent still pending (John Myre)
Re: Is there an algorithm to sequentially enumerate all transcendental numbers?
("Henrick Hellström")
Question about password hashing and hash chaining ([EMAIL PROTECTED])
Re: Is there an algorithm to sequentially enumerate all transcendental numbers?
("Paul Lutus")
Euler's totient function and factoring (Stefan Katzenbeisser)
Re: Is there an algorithm to sequentially enumerate all transcendental numbers?
(stanislav shalunov)
Re: Is there an algorithm to sequentially enumerate all transcendental (jtnews)
Re: Ciphile Software: Why .EXE files so large (Richard Heathfield)
Re: Is there an algorithm to sequentially enumerate all transcendental (Richard
Heathfield)
Re: Is there an algorithm to sequentially enumerate all transcendental numbers?
("Paul Lutus")
Re: Is there an algorithm to sequentially enumerate all transcendental numbers?
("Paul Lutus")
Re: Euler's totient function and factoring ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Big Numbers in C/C++
Date: 19 Feb 2001 12:17:28 +0100
In article <[EMAIL PROTECTED]>,
JCA <[EMAIL PROTECTED]> wrote:
> Dann Corbit wrote:
>
>> "JCA" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>>> Paul Schlyter wrote:
>>>
>>>> In article <[EMAIL PROTECTED]>,
>>>> David Sowinski <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> I prefer GMP and believe that it is faster than MIRACL.
>>>>
>>>> Did you use just the C low-level routines in MIRACL when evaulating
>>>> the speed? MIRACL also has assembly language replacements for these
>>>> for the most popular processors,
>>>
>>> So does GMP.
>>
>> MIRACL is a lot easier to use.
>
> GMP is quite easy to use. At least, I have never had any problem with it.
>
>
>> The speed might be a push, but you also have a ton of algorithms already
>> implemented.
>
> Fair enough. I was just interested in the big integer stuff. anyway.
>
>> Besides which, C++ classes are so much easier to understand.
>
> Whoa, I dispute that! I have no love for C++, I am sorry to say.
You don't have to use the C++ wrapper classes in MIRACL -- underneath
them there's a traditional C interface which you can use directly, if
you prefer so.
>> MIRACL is a lot better (for me -- YMMV).
>
> Good for you!
--
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se orpaul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pauschhttp://welcome.to/pausch
--
From: "ajd" <[EMAIL PROTECTED]>
Subject: RSA on FPGA
Date: Mon, 19 Feb 2001 12:40:46 -
Anyone ever done it? Which bits of the algorithm were implemented?
Andrew
--
From: "Henrick Hellström" <[EMAIL PROTECTED]>
Subject: Steak (again)
Date: Mon, 19 Feb 2001 14:29:37 +0100
Some of you requested an updated and more thorough documentation of Steak. I
have attempted to do so, and I would be pleased if any of you could take a
look and comment on the results. I would in particular appreciate comments
about unconventional terminology (which, for some reason, tend to upset some
people), logical or computational errors, and, of course, any kind of
relevant attack on th
Cryptography-Digest Digest #715
Cryptography-Digest Digest #715, Volume #12 Tue, 19 Sep 00 08:13:01 EDT
Contents:
Simple hash function ("dexMilano")
Stream cipher ([EMAIL PROTECTED])
Re: [Q] Design criteria for sboxes in Tiger/192 ? (Ross Anderson)
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an (Mok-Kong Shen)
Re: Simple hash function (David Blackman)
Re: Optimization for speed question. (Christian Bau)
Re: Simple hash function ("dexMilano")
Re: Intel's 1.13 MHZ chip (Robert Stonehouse)
Re: Simple hash function (Anders Thulin)
Re: Lossless compression defeats watermarks (Ross Anderson)
Re: Chosen and known attacks - are they possible ?? (Guy Macon)
Re: "Secrets and Lies" at 50% off (Felix von Leitner)
Re: Double Encryption Illegal? (Guy Macon)
Re: QUESTION ABOUT ALGORITHMS (Runu Knips)
Re: Weak keys in RC4 (Guy Macon)
Re: Stream cipher (Runu Knips)
Re: Simple hash function (Runu Knips)
Re: Q: Crypto-PC (Runu Knips)
Re: Software patents are evil. (Runu Knips)
From: "dexMilano" <[EMAIL PROTECTED]>
Subject: Simple hash function
Date: Tue, 19 Sep 2000 10:13:02 +0200
I'm loloking a very simple/fast hash function to identify if a record in a
table has been modified since last check.
I've seen standard hash but they'r too heavy to execute in a demon process
(that works in background with a low CPU consumption).
I've not problem of protection/integrity because all changes should be safe,
it's just a way to understand if the record has been modified by another
application.
Any suggestion will be welcome
dex
--
From: [EMAIL PROTECTED]
Subject: Stream cipher
Date: 19 Sep 2000 08:42:16 GMT
I work for a company which is developing a conditional access system for
the European digital audio broadcast project and I am trying to implement
a stream cipher with low resource requirements and (guess what) good
cryptographical properties, i.e. it should be small and secure. The data
to be encrypted is mostly binary (audio streams). Furthermore, the
encryption algorithm should be free and not patented (no RC4 or SEAL or
Shareware). Currently, the whole system is being implemented in software,
but plans exist to realize it in hardware.
Can anyone recommend a suitable algorithm? In AC of Schneier resp. HAC
of Menezes a few generators based on LFSRs are mentioned, e.g. such as
the shrinking / self-shrinking generator, the alternating step generator
or the knapsack alg., but only little information about their security
is given (mostly because they were too new at that time). I don't know
if there have been any successful (practical) attacks against on these
algorithms, but maybe someone can supply me with more up-to-date
information than that stated in the books (or other algorithms I don't
know about yet).
Thanks,
Andi
--
From: [EMAIL PROTECTED] (Ross Anderson)
Subject: Re: [Q] Design criteria for sboxes in Tiger/192 ?
Date: 19 Sep 2000 08:46:47 GMT
In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> writes:
>It also has a nice paper which describes almost
>everything except the design of the Sboxes. Does
>anyone have any information (or an idea) how they
>have been constructed ?
For how we designed the Tiger S-boxes, see the `S-box
generation documents' at:
http://www.cl.cam.ac.uk/users/rja14/#Cryptanalysis
Ross
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an
Date: Tue, 19 Sep 2000 11:08:08 +0200
Kostadin Bajalcaliev wrote:
>
[snip]
> Main question is what is the essence of security, how to define and name
> that phantom substance the designers put in their work. And make the rest of
> us to wander how a simple design as RC5 or Blowfish can be secure on one
> side. On other the homemade cipher having kilometers (or miles if you
> prefer) of code and complicated mathematical theory behind may serve just as
> scholar example of weak design.
We have indeed discussed long ago that there is no
rigorous and practically applicable scientific unit
for measuring the strength of an encryption algorithm
like second, Newton etc. The security of applying
an algorithm depends on the environment and the
user's evaluation of the security can at best be
a more or less subjective value. One never knows
whether the best esteemed cipher will not be easily
broken by a new method in the future, nor even that
it has not already been broken by some secret agency.
The majority of ciphers don't have good and complete
documentation and almost invariantly contain constants
that a third party has no information to reproduce.
Thus even the question of presence of backdoors
cannot be definitely a
Cryptography-Digest Digest #715
Cryptography-Digest Digest #715, Volume #11 Sat, 6 May 00 04:13:01 EDT
Contents:
Two basic questions (kidwalden)
Re: Two basic questions (Tom St Denis)
Re: Crypto Export (David A Molnar)
Re: Two basic questions (David A Molnar)
Newbie question about generating primes ("JoeC")
Re: new Echelon article ([EMAIL PROTECTED])
Re: Any good attorneys? (Joaquim Southby)
Re: Crypto Export (Bill Unruh)
Re: Newbie question about generating primes ("Dann Corbit")
Re: RC5 math (Scott Contini)
Re: Unbreakable Superencipherment Rounds (wtshaw)
SV: cryptographically secure ("Ali Tofigh")
SV: cryptographically secure ("Ali Tofigh")
From: kidwalden <[EMAIL PROTECTED]>
Subject: Two basic questions
Date: Fri, 05 May 2000 22:05:58 -0500
Forgive me, I'm just starting to learn about crypto to keep from
becoming bored stiff at school. I have two basic questions:
Why don't people just use bad spelling and/or grammer before encrypting
messages? If my plain text reads "We-uns gonna tack purl harber
toonite" and I take reasonable trouble to not be consistent in my
misspellings, it seems like even a simple substitution cipher would
throw off most machines for a long time. After all, nothing would match
a dictionary lookup...
Also, has anyone ever made a true random number generator for a PC,
using some truly random event like beta decay or diode noise?
Thanks for your patience with this newbie!
Walden
--
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Two basic questions
Date: Sat, 06 May 2000 03:31:23 GMT
kidwalden wrote:
>
> Forgive me, I'm just starting to learn about crypto to keep from
> becoming bored stiff at school. I have two basic questions:
>
> Why don't people just use bad spelling and/or grammer before encrypting
> messages? If my plain text reads "We-uns gonna tack purl harber
> toonite" and I take reasonable trouble to not be consistent in my
> misspellings, it seems like even a simple substitution cipher would
> throw off most machines for a long time. After all, nothing would match
> a dictionary lookup...
For the simple reason I know you are saying "We are gonna attack perl
harbor tonight".
> Also, has anyone ever made a true random number generator for a PC,
> using some truly random event like beta decay or diode noise?
Yeah, Mike Rosing used Americium I believe to make a rng...
> Thanks for your patience with this newbie!
Hey I think all serious crypto people start this way (being bored at
school) I know I did.
Tom
--
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Crypto Export
Date: 6 May 2000 03:15:26 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
> other crypto since it was already included. (Crypto is one product which
> you cannot test the output to see if it does what it claims to do-- bad
> crypto and good crypto look the same to the user.)
I suppose one answer to this is peer review from people who know how to
tell the difference. Open source seems to help this, although if
something's popular enough it will be reverse engineered and you can
always hire people under NDA. Part of the problem though seems to be
that you have to say "good crypto for what??" it's not enough to be
unbreakable, the protocol has to work as well.
This reminds me of a question I had :
Sometimes you have an application sitting on your hard drive which
sends encrypted data over an outgoing connection. How do you verify
that this encrypted data is what you think it is, no more no less?
Is it worth spending time on protocols for which a legitimate user
can sniff his own connection, and then prove to himself that ONLY
what he thinks is going out is going out? (i.e. no subliminal
channels). That is, for every protocol executed by the software,
there exists a "verification protocol" which checks to make sure
only the specified info is being passed and that the protocol isn't
broken from a passive adversary point of view.
If it is, then what would satisfy you as a real-world implementation of
the verification protocol? That is, what would a real world
"verifier" look like? It seems like the verifier shouldn't be
written by the same people who wrote the original software. Ideally it
would be simple enough to code yourself, like CipherSaber, and you could
use it to "bootstrap" to larger pieces of code. Maybe next best is to
have lots of verifiers available as source from lots of independent
people.
The immediate application I can think of is remote login and password
verification protocols. Very important protocol, several messages going
back and forth, fairly tricky software to code _right_, and so on. Plus
nast
Cryptography-Digest Digest #715
Cryptography-Digest Digest #715, Volume #10 Fri, 10 Dec 99 02:13:01 EST
Contents:
Random Numbers??? (John)
Re: Digitally signing an article in a paper journal ("Trevor Jackson, III")
Re: Synchronised random number generation for one-time pads ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
Re: Random Noise Encryption Buffs (Look Here) ("Trevor Jackson, III")
From: John <[EMAIL PROTECTED]>
Subject: Random Numbers???
Date: Thu, 09 Dec 1999 22:27:17 -0800
I have been kicking around random # generators. I have 3 sets of 1000
random #s. Are they? How can you tell? Integers range from 0 through
255 inclusive.
Set1---Set2---Set3
113126114
227 80140
165240210
24211242
122139 44
225125146
104 77197
152194194
195246 35
124 23212
225121120
105 34169
112194 41
222100 92
203118 65
97158188
22188241
13185140
51231 58
40254203
210165205
215 31109
102110 83
169239172
205229191
253253105
134252 27
21 5178
100 16 58
130 4 97
250132104
181 78159
117 88242
179 4 27
158 65222
184 37108
97 71 93
218253 36
20 63222
254 94 74
12198 62
177239 36
169237219
30 89 95
230202252
213 11250
147 68109
128252230
68 86 55
139115253
90160104
66221 29
2111 56
65 16236
89155 37
130 4 43
204 15 47
241 13100
197 60 52
194174182
77 9225
3229 91
86 85251
133159142
64188 57
159 92 12
203177 18
233152213
26170115
132195110
200175123
108126225
52144 31
28228198
87 63245
187127 18
235138125
113137107
144222155
10 69115
31210233
99255184
209122158
99 36 55
155 41111
167206179
171217146
176158 40
116 2 71
182 74237
89238 12
98 95 65
219137 96
184233101
187159100
234109 63
234 64 24
35 61 64
86 17159
177 17 86
89 21 87
121 1136
44244137
97143 90
0110241
23192137
214110 41
46 82 30
224 27 19
25134223
133 33 95
119111221
189232117
25231128
91 56 82
82234251
64108 83
182193 36
210192229
69 30 7
0 32110
180 7186
183 57241
11232225
133125251
217172166
141111 78
58165214
161 75242
52181 74
182147155
245 79152
85169194
190 2254
61102141
217107120
254 83207
175 38159
239186136
104 99101
13239112
102137 96
78 99120
34194151
205245207
115141173
109147197
230226 84
33177202
193 17 30
33230168
177254129
149186174
102184 50
129170 58
113 67192
35165 36
139101220
191164184
85127177
249198 72
241135198
62142121
95211 26
37142227
144160233
167161238
85153218
114 32 62
132 88120
194179 9
94 23 34
157 0239
55184 16
40191112
123 70 64
95 90 55
233107229
60244164
209 73 86
156232139
62107 45
81 72164
81109 85
69201223
201 19183
44183 41
162 8 86
9144143
60 9 18
44126251
11 93169
137 24119
101 65110
248243 90
50119 38
103 0255
185175220
107173194
7 68162
194 75212
140239121
151 48 43
198187228
147209102
196 49231
161 9138
162162 86
115 97
Cryptography-Digest Digest #715
Cryptography-Digest Digest #715, Volume #9 Mon, 14 Jun 99 01:13:03 EDT
Contents:
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: "Breaking" a cipher ("rosi")
Re: DES lifetime (was: being burnt by the NSA) (Bill Unruh)
Re: Generating Random Numbers (Herman Rubin)
Re: Slide Attack on Scott19u.zip (SCOTT19U.ZIP_GUY)
Re: OTP is it really ugly to use or not? (fungus)
Re: Is there a short digest for short messages? ([EMAIL PROTECTED])
Re: Cracking DES (Terry Ritter)
Re: Slide Attack on Scott19u.zip (David Wagner)
Export restrictions question ([EMAIL PROTECTED])
Re: OTP is it really ugly to use or not? (fungus)
Re: MD5 test data ("yychiang")
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Slide Attack on Scott19u.zip
Date: Mon, 14 Jun 1999 00:58:46 GMT
In article <7k0r6t$4mv$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>Well I just got out of the shower, how did you know that? Most
>contests have a purpose. The DES challenge was to show that the key
>could be searched really quickly. The Twofish team put $1 dollars
>where their math is. They put the money towards the first person to
>break the cipher, not a message. You could do the same.
>
Actually Tom your wrong the break that this phony contest is willing
to pay for is not black and white. Its for a paper attack that Mr B.S. thinks
is worth rewarding. If some one like me solved it I would get zero. I think
even if Paul Onions came up with a decent break he would get nothing.
But later when one of the crypto clubers writes up Pauls attack the other
crypto god would get the money if it is deemed good enough by the crypto
gods.
I offer a contest that is black and white it is either solved or not.
His is like as essay contest. Some people good at BSing are good
at those kind of tests. I guess I am more a multiply chioce kind of guy.
Also the kind of contest the crypto gods run limits the hacker types
from bothering to look. They are scared to death to run a real contest
becasue some nobody could post a solution here. But a nobody who
write an honest attack that was not skilled in the narrow vocabulary that
they use would have zero chance to win.
Look at what I have. Code that the crypto gods both of them said was
dead. Think about Dave Wagner said scott19u was dead years ago. Of
course he will say that was the one Paul Onion solved. Since he has to
make up something. But the truth of the matter is Crypto Gods don't ever
want to say good about a cipher unless your in the Club. Yes I expected
Mr BS and or Dave W. to say things like the Slide Attack makes it dead but
they know better. How about trying to get some honest anwsers from them
about scott19u. You will not other than them saying the key that can be used
is to big or they personally consider it to slow. But is there a weakness in
how it encrypts. You can beat your ass that if they had one they would
mention it but they don't. Sorry that it is to strong for the toy break so
much for the slide attack.
Tom the main reason the Crypto Gods Slide Attack failed is that they are
only use to very narrow ideas in crypto. There minds are closed to the other
ways of doing things. Kind of like the Swiss watch makers when the Japanese
came out with quartz watches. The Swiss where slow to change becase they
thought they new all about watches. The crypto gods are the same way. But
they may know a little more than the Swiss it is just they think they can
control the course of crypto in the world so that through contests like the
AES the NSA will still be able to read your encrypted mail.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
--
From: "rosi" <[EMAIL PROTECTED]>
Subject: Re: "Breaking" a cipher
Date: Sun, 13 Jun 1999 19:49:41 -0400
Dear Bernie,
Not here to answer your difficult question. Just would like to let you
know that I think you are not alone in the unresolve.
Certain simple things such as what is a block cipher and what is
a stream cipher can end up in one throwing up his arms and declare
"it's up to you". :)
So sleep soundly and do not let this really bother you too much.
Your common sense can be the best guide.
--- (My Signature)
Bernie Cosell wrote in message <[EMAIL PROTECTED]>...
>In a bunch of threads [mostly fueled by PR from the EFF], folks keep
>talking about "breaking" DES" and "breaking RSA" and such. There's a
>semantic problem here for me that I need some help with:
>
>Every key-based system is "breakable". The only inte
