Cryptography-Digest Digest #644, Volume #13 Tue, 6 Feb 01 19:13:01 EST
Contents:
what code is this? (Eric Lehman)
Affordable High-Quality Patents (PatentWeaver)
Re: CipherText patent still pending (Bryan Olson)
1 to 4 byte hash function ("Akita Bright-Holloway")
Re: Actually I monitored activities of this =?iso-8859-1?Q?NSA=B4s?= (Kenneth C
Stahl)
Re: Scramdisk, CDR and Win-NT (Michael Robbins)
Re: Encrypting Predictable Files ("Joseph Ashwood")
Re: Encrypting Predictable Files ("Joseph Ashwood")
Re: 1 to 4 byte hash function ("Joseph Ashwood")
Phillo's alg is faster than index calculus ([EMAIL PROTECTED])
Re: Mod function ("Adam Smith")
Re: Phillo's alg is faster than index calculus (Bob Silverman)
Re: Phillo's alg is faster than index calculus (Tom St Denis)
Re: Scramdisk, CDR and Win-NT ("Sam Simpson")
----------------------------------------------------------------------------
From: Eric Lehman <[EMAIL PROTECTED]>
Subject: what code is this?
Date: Tue, 06 Feb 2001 17:00:23 -0500
I'm sure the following coding technique is known. I'm curious how one
could attack it.
A ciphertext is a sequence of subscripted letters, such as
A_3 H_5 E_3 L_6 E_9 L_6 W_2 W_7 O_8 M_4
where the subscripts are the range, say, 1 to 10.
The key associates each letter of the alphabet with a number in the
range 1 to 10.
To read the message, cross out each letter whose subscript is not the
number specified in the key.
For example, the key to the above message might be (in part):
A - 1
...
E - 3
...
H - 5
...
L - 6
M - 2
...
O - 8
...
W - 5
...
The first letter of the ciphertext is A_3, but A is associated with 1 in
the key, so we cross it out. The second letter is H_5, and H is
associated with 5 in the key, so we keep it. Continuing in this way, we
can extract the plaintext:
H_5 E_3 L_6 L_6 O_8 = HELLO
Suppose that that ciphertext is padded to about ten times the length of
the plaintext so that each letter occurs about an equal number of times
with each subscript. How could one attack this system?
Multiple decodings are possible-- for example, I could subscript all the
characters of Hamlet with 1's and interleave all the characters of Romeo
and Juliet with 2's. Then you couldn't determine whether my plaintext
was Hamlet or Romeo and Juliet. But you could certainly say, "This is
either Hamlet or else Romeo and Juliet". So let's say the system is
broken if the attacker can extract a small collection of long, coherent
messages, one of which is the actual plaintext. How could such an
attacker proceed?
/Eric
------------------------------
From: PatentWeaver <[EMAIL PROTECTED]>
Crossposted-To: biz.misc,biz.mlm,sci.electronics
Subject: Affordable High-Quality Patents
Date: Tue, 06 Feb 2001 22:01:51 GMT
www.patentweavers.com
Patent Weavers provides experienced software, hardware and business
method patent research and writing. Expert at infringement & validity
analysis, we've supported some of the world's foremost technology
companies in patent litigation. We specialize in IT patents at all
levels of complexity, and offer low cost patent work for simple
mechanical and electrical patents.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Tue, 06 Feb 2001 22:04:26 GMT
wtshaw wrote:
> Bryan Olson:
[...]
> > Only analysis of ciphers does that. Though we do need
> > ciphers in order to do analysis, we're already way, way
> > overstocked.
> >
> Which means that you feel most copmfortable in a small and
> dependable wold that tends not to challenge you too much?
> OK, no real slam here intended, but anyones frustration
> about the growth of information and knowledge should not
> hamper those that wish to press on.
The symmetric cipher designers here are not accepting any
challenge at all. Of course anyone can design a cipher. They
don't add to knowledge; they add to conjecture, and even that
is a trivial variant of the conjectures about the scores of
other ciphers.
> Rather than expecting to know it all, we are now into
> specialization in crypto, with decreasing common ground.
Quite a thing to be bad at one's specialty.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Akita Bright-Holloway" <[EMAIL PROTECTED]>
Subject: 1 to 4 byte hash function
Date: Tue, 06 Feb 2001 15:24:12 +0700
Ok, so i tend to just do alot of server side programming, which means my
standard approch for putting together a program is to build my tools that
im going to need, then build my functions, then build my program for
whoever is buying it. Currently im writting a point of sales software for
a resteraunt with multiple locations, so for any communications outside
of each location, im going to be needing some cryptography on my side. I
heard you guys scrutinize (sp) alot, and thats what i need and want :)
First question should probabbly be, is it wise to even make a series of 1
- 4 byte hashses, to be latter used in a bigger better hash function, or
should i just start making a bigger badder hash function right away, with
some of the 1-4 byte hashes that iv been toying with, i *try* to make it
so that the origional character is unrecoverable, even if you have the
origional seed ... is that a good thing or a bad thing when we start
doing a good number of these hashes to hash a string ? am i going to
start seeing alot more collisions when i hash a string together if im
loosing my single characters ? (my thoughts were that since im esentially
creating 4 characters out of this one based on the seed, that i can be
using those 4 characters to do some stuff with the rest of the sting ...
havnt goten that far to specify how, but whatever, just magically do some
spiffy stuff right ? - but if ill be doing that then any change in even a
small value between 56 to 57 or something, should be changing just about
every other bit in the end hash, or so thinks i ... is this remotly
true?) - no i havnt taken any cryptography courses in specific, so i
would love some of you who have to tell me if any of that is wrong, or
how i could be improving that :) , so basically now that you know that my
goal is to create a series of hash functions based on a series of 1-4
byte hash functions, let me ask the question about what kind of goals i
should be aiming for in my 1-4 byte hash
Ok, so say i have a 1 byte character, and a 4 byte seed, and i put it
through my hash function, which will give me a hashed 4 byte number,
standard idea of a hash is to make it very hard to extrapolate the
origional character and seed. the other idea is to make it hard to
replicate that hash with a different character and seed, now with a 1-4
byte hash, its not going to be that hard ... we could very easily
generate a hash table of all the possible outputs (yea, using quite a bit
of ram, but we really dont need the whole table right? i ran into
collisions generating a small table of catologing all the seeds between
0-4095 and all characters 0-255), - of course, some collisions arnt
nessisarily a bad thing, or is that a false statement ? its obvious im
going to have some colissions because im squeezing 5 bytes into 4, so no
matter what algorithim i dream up, thers gona be collisions ... So, i
guess my actuall question(finnally) is this, what are some good numbers
to aim for, for creating uniqe hashes, and even whats a good number of
collisions to be aiming for ? Also, i know theres a mathmatical way of
proving collissions and cool stuff, anyone got any tidbits on that ? i
dont want to be writtings a program to go through and check through for
collisions seed by seed, if i dont have to atleast ....
Thanks for any and all input i get from this group :) it looks like you
guys know your stuff, i know you guys are picky about spelling, me and
english never got along all that well, thats why im a programmer i guess
right? the compiler doesnt care ... heh, but if you correct me on any
spelling ill correct my self ... :)
- Akita
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Posted via Usenet.com * RETENTION * COMPLETION * SPEED *
http://www.usenet.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
------------------------------
From: Kenneth C Stahl <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,soc.culture.nordic,soc.culture.russian
Subject: Re: Actually I monitored activities of this =?iso-8859-1?Q?NSA=B4s?=
Date: Tue, 06 Feb 2001 22:27:43 GMT
Amaury Jacquot wrote:
>
> how do you expect us to read the message if everything is in the subject...
>
> "Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote in message
> news:95pa8e$c1a$[EMAIL PROTECTED]...
He never says anything worth reading anyhow, so it really doesn't
matter.
------------------------------
From: Michael Robbins <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Scramdisk, CDR and Win-NT
Date: Tue, 06 Feb 2001 22:36:07 GMT
> Yes, simply mount and then you can access the contents as per a normal
> (hard drive based) container.
<snip>
> Don't use NTFS on the volume and you will be fine.
Thanks again. It works wonderfully -- very easy to use.
I was thinking of using a CDWR for my less speed sensitive files, any
comment?
--
Michael Robbins, CFA
Director, Debt Capital Markets
Canadian Imperial Bank of Commerce, World Markets
New York
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Tue, 6 Feb 2001 14:54:57 -0800
"Bryan Olson" <[EMAIL PROTECTED]> wrote in message
news:95plt8$o9q$[EMAIL PROTECTED]...
> Paul Housley wrote:
> [...]
> > There are some parts of the files which are predictable.
> [...]
> > I am concerned that, by knowing what part of the file is
> > supposed to decrypt to, this may help people to find the
> > encryption key.
> >
> > Any advice, particularly concerning the RC4 algorithm?
>
> RC4 is designed to resist known-plaintext attacks, and so far
> no one has shown it doesn't.
However it also suffers from plaintext substitution, that is to say that if
the plaintext is known it can be replaced with a different more desirable
plaintext, this may or may not be a problem depending on the situation.
Because of this I'd suggest using at a minimum an AllOrNothingTransform.
Realistically that'll be as expensive as using a block cipher that doesn't
suffer from this problem.
> It is _not_ designed to encrypt multiple messages with the
> same key. Always derive a new key RC4 key for each message.
No argument at all, this is an absolute MUST.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Encrypting Predictable Files
Date: Tue, 6 Feb 2001 14:51:36 -0800
<[EMAIL PROTECTED]> wrote in message news:95prlb$ttg$[EMAIL PROTECTED]...
> Good encryption does not add information.
Let's test that theory carefully against the only proven perfect cipher,
OneTimePad (OTP). The proof of OTP goes something like the following
(assuming XOR).
Given a purely random stream S
given a plaintext P of some amount of entropy greater than 0
By XORing the S with P to create X the resultant X will have entropy at
least equal to maximum(entropy(S), entropy(P)), which since we know that S
is purely entropic will be entropy(S)
Since the result is purely entropic no attacks can be mounted against it.
Realize that entropy is a measure of information.
Assume "Good encryption does not add information"
Given earlier proof about OTP adding information
Given OTP is perfect and good
Therefore we have a contradiction, therefore DS is wrong
<sarcasm>That's a surprising result if I ever saw one.</sarcasm>
I'm sorry DS but you are wrong as usual, unless you would care to claim that
OTP is not good cryptography? In which case I'd like a proof from you, even
at the fair amount of handwaving level that I gave.
Now on to the other statement I addressed before
Earlier claims by DS in this thread:
Matt Timmermanns Rijndael implementation does not add information.
Matt Timmermanns Rijndael implementation changes the length of files
So you have once again proven yourself incorrect in at least one way. Now
since I'm tired of clogging the NG I'm going to leave DS alone while he
tries to figure out whether or not logic applies in his world or not, so I
will no longer reply to him (or others replying to him) in this thread.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: 1 to 4 byte hash function
Date: Tue, 6 Feb 2001 14:38:24 -0800
"Akita Bright-Holloway" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
[on a 1-4 byte hash]
Regardless of how good the function itself is, it can be directly mapped out
in RAM on a machine, from this breaking it is as simple as a lookup.
As to whether or not this would be useful when used in conjunction with
another hash function. No it would not, the best you could hopre for would
be for the result to have as much strength as the outer-most hash function.
This can be proven mathematically by observing that by using intermediate
hash functions you can not increase entropy, but you can lose it.
I think I see where this is going though. I'd recommend very strongly
against creating your own hash function. There are several very fast, very
secure hash functions available for whatever your needs are. The most likely
candidates are MD5 and SHA-1 both have many freely available
implementations, I'd recommend you start with openSSL (www.openssl.org)
Joe
------------------------------
From: [EMAIL PROTECTED]
Subject: Phillo's alg is faster than index calculus
Date: Tue, 06 Feb 2001 23:19:50 GMT
(I'm not talking about breaking RSA. So no need to flame rightaway :) )
In terms of solving discrete log, I think it's faster than index
calculus. Isn't index calculus the fastest available algorithm?
Using his example: 2^x = 1 mod n
1. His method does NOT use multiplication, exponentiation, division etc.
All we do is add. We can also make part of the addition into bit
comparison...
2. Theoretically, we need x operations. But in practice, we don't.
Sisi's conjecture: worst-case scenario will never happen.
Take his example. x=20. But we only need 7 operations. If you get a
lucky n, eg. n=10101...........0101, we only need 2 operations.
3. We can deal with say 100 bits instead of 1 bit at a time. We can
precompute entries with the appropriate ending bits. Then we'll be doing
bit comparisons for 100 bits and addition for the remaining bits.
Precomputing entries is used in all methods I know of. So I think it's
plausible.
4. Unlike index calculus, we don't use any trial and error.
Everything's straight forward. We simply can't go wrong. So there won't
be an unlucky day.
So what do you think?
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Adam Smith" <[EMAIL PROTECTED]>
Subject: Re: Mod function
Date: Tue, 06 Feb 2001 23:31:45 GMT
I am looking for a mod function that can work on lery large (100+ digit)
numbers...
"Nemo psj" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> in VB mod is already built in
>
> Buf = 500 mod(255)
> that will mod 500 to 255
>
> nice ha? I can give a a hand made one if you need it e-mail me.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Phillo's alg is faster than index calculus
Date: Tue, 06 Feb 2001 23:39:48 GMT
In article <95q0qb$32s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> (I'm not talking about breaking RSA. So no need to flame
rightaway :) )
>
> In terms of solving discrete log, I think it's faster than index
> calculus. Isn't index calculus the fastest available algorithm?
>
> Using his example: 2^x = 1 mod n
>
> 1. His method does NOT use multiplication, exponentiation, division
etc.
> All we do is add. We can also make part of the addition into bit
> comparison...
>
> 2. Theoretically, we need x operations.
You are severely confused. n is known. x is to be determined.
> 4. Unlike index calculus, we don't use any trial and error.
You clearly do not know how the index calculus algorithms work,
since they do not use trial and error.
>
> So what do you think?
I think you need to do a lot of studying.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Phillo's alg is faster than index calculus
Date: Tue, 06 Feb 2001 23:40:46 GMT
In article <95q0qb$32s$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> (I'm not talking about breaking RSA. So no need to flame rightaway :) )
>
> In terms of solving discrete log, I think it's faster than index
> calculus. Isn't index calculus the fastest available algorithm?
>
> Using his example: 2^x = 1 mod n
>
> 1. His method does NOT use multiplication, exponentiation, division etc.
> All we do is add. We can also make part of the addition into bit
> comparison...
>
> 2. Theoretically, we need x operations. But in practice, we don't.
>
> Sisi's conjecture: worst-case scenario will never happen.
>
> Take his example. x=20. But we only need 7 operations. If you get a
> lucky n, eg. n=10101...........0101, we only need 2 operations.
>
> 3. We can deal with say 100 bits instead of 1 bit at a time. We can
> precompute entries with the appropriate ending bits. Then we'll be doing
> bit comparisons for 100 bits and addition for the remaining bits.
> Precomputing entries is used in all methods I know of. So I think it's
> plausible.
>
> 4. Unlike index calculus, we don't use any trial and error.
> Everything's straight forward. We simply can't go wrong. So there won't
> be an unlucky day.
>
> So what do you think?
I think you are full of it.
Given
p=C0B3A0B1FFCAB1F8B240F1F0E5AE4AEC2438AC0063C0D228386860CE80124257
g=3
x=??? who knows ???
g^x = 909E7ACDCA5C1E9511E4115DEEBDC33F2683B70D3728405A324962F168A5634A
Ask phili boy to find x using his algorithm. (Values are in hex).
Tom
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.scramdisk
Subject: Re: Scramdisk, CDR and Win-NT
Date: Tue, 6 Feb 2001 00:02:30 -0000
As long as you accept that you can't 'write on the fly' to the disk, then
'no', everything should work just fine.
Basically you still need to create the SD container file on a hard drive,
fill it full of files etc and then write the container to a CD-RW...But at
this point the container is totally read-only. If you want to change files
then you need to copy the .SVL back to a hard drive, change the files, then
write the .SVL file back to a CD.
--
Regards,
Sam
http://www.scramdisk.clara.net/
Michael Robbins <[EMAIL PROTECTED]> wrote in message
news:95pu8m$n0$[EMAIL PROTECTED]...
>
> > Yes, simply mount and then you can access the contents as per a normal
> > (hard drive based) container.
> <snip>
> > Don't use NTFS on the volume and you will be fine.
>
> Thanks again. It works wonderfully -- very easy to use.
>
> I was thinking of using a CDWR for my less speed sensitive files, any
> comment?
>
> --
> Michael Robbins, CFA
> Director, Debt Capital Markets
> Canadian Imperial Bank of Commerce, World Markets
> New York
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
