Cryptography-Digest Digest #213, Volume #12 Wed, 12 Jul 00 15:13:00 EDT
Contents:
Re: Base Encryption: Strongest Cypher (James Felling)
Re: Elliptic Curves encryption (DJohn37050)
Re: Questions!!!! (David A. Wagner)
Re: Limits of brute force. (Dido Sevilla)
Re: Proposal of some processor instructions for cryptographical applications (Jan
Vorbrueggen)
Re: RC4-- repetition length? (John Myre)
Re: Random Numbers ("Paul Pires")
Re: cray and time needed to attack (Jerry Coffin)
Re: cray and time needed to attack (Jerry Coffin)
Re: exports? (Paul Koning)
Newbie Question (Stephen Hui)
Re: RC4-- repetition length? (Bill Unruh)
Re: 3DES Bruce Schneier, Applied Crypto CD? (Bill Unruh)
Re: Random Numbers (Bill Unruh)
Re: Public/Private Key crypting ("Joseph Ashwood")
Re: Newbie Question ("Joseph Ashwood")
Re: Questions!!!! (Helger Lipmaa)
Re: Proposal of some processor instructions for cryptographical applications
("Thomas Womack")
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Strongest Cypher
Date: Wed, 12 Jul 2000 11:12:16 -0500
[EMAIL PROTECTED] wrote:
> The following describes the main features of Base Encryption.
> I will try to address legitimate points made by other in previous
> posts. For the rest, I suggest you seriously read the paper and
> understand it before making comments. Childish attacks covering
> up an inherent fear, or those that simply still don't get it,
> will simply be ignored (you know who you are). Read the previous
> Advanced Encryption FAQ if you are still having a difficult time
> sitting down and admitting the truth about Base Encryption.
> I have yet to find someone who can find a fault with Base Encryption.
> I have yet to find someone (maybe one, and I am addressing it here) who
> came close to making a scholarly comment on it.
> Is everyone here a reflection of the analytical abilities of the
> encryption community? I certainly hope not. I guess text-book
> trained minds can't think outside of the box. Come on, I challenge
> you: make a scholarly analysis of it with references. I have yet
> to find a post from someone who can really think, who can use their
> brains and not trapped behind a big ego.
>
> More info: http://www.edepot.com/phl.html
> Base Encryption
>
> Main Strengths:
> 1) Immune from plain-text-attacks.
> 2) Immune from brute-force-attacks.
> 3) As secure as OTP
> 4) Can utilize throwaway algorithms.
> 5) Dynamic Algorithms (operators and operations)
> 6) Dynamic Base (symbol set)
> 7) Plug-And-Play engine (other cyphers can be augmentated to it)
>
> 1) Immune from plain-text-attacks.
>
> It is immune from plain-text-attacks because multiple algorithms
> can generate same plaintext. Multiple algorithms can generate
> same cyphertext. It is like saying how many ways are there to
> come up with 12345? (infinite: 12344+1, 12343+2, 1+1+1+12342, etc)
This is like claiming that one is imune to being mugged because you can
choose an infinite number of routes between point A and Point B. Given
that I(person A) am actually using this method to comunicate with person B
I will have agreed upon a formula or method that we are to use to send
messages. Yes we may assume that the adversary does not know our method of
encryption, but if a few known plaintexts are sent by this method the
analyst will have a very good chance of recovering the message. I agree
that this method is secure as long as the choice of base and operations is
totally random, but once a method is agreed upon to let me read a message,
the method is then subject to attack.
>
>
> 2) Immune from brute-force-attacks.
> It is immune from brute-force-attacks. A lot of pepple on this
> forum simply do not understand this. Read the Garage Door example,
> then the Chinese Newspaper, then come back to me. It is exponentially
> expensive. Then when you come back to me, and STILL don't get it.
>
> Get this...
> You don't know when you have the correct key. There is no way to
> find out. Because multiple algorithms can generate a text, you have
> no way to verify you have the correct key. So you can permutate the
> hard way, starting with 1 bit, then to 256 bits. Going through
> the values for EACH bit increase (rather than the current weak cypher's
> starting point at 256 bits (value 0) and end at 256 bits (value 256).
> Then after you permutate through all the keys, you have NOTHING!!!
> You don't know when you have found the answer. It is immune from
> brute-force-attacks on the basis the INABILITY for you test against
> the engine and know when you have the right key.
You are vulnerable to brute force in practice. Given A and B have a method
that is used to comunicate between them. They have a defined set of
operations that they use to encrypt/decrypt. At that point that channel is
vulnerable to brute force. Because I may then try bases and operations
until such time as I arive at a decryption -- yes this is perhaps more
resistant than some other methods to brute force, and has ( in all
probability) a rather large unicity distance, but any given channel will
be capable of being attacked by brute force.
>
>
> 3) MORE secure as OTP.
> For those that still dont "get it". Here is a clue: Think of
> each piece of paper on the pad as a dynamic algorithm in Base
> Encryption.
>
> Now, you can use plain text attack on that piece of paper on the One
> Time Pad. Can you do that on Base Encryption? NO.
The only time OTP falls to a plaintext attack is if it is Not OTP( i.e. if
you reuse the pad). This claim is bunk. Theis is saying " this method is
more secure than OTP if you misuse OTP. I'll accept that, but such a claim
is like saying that my car is faster than any porche, ferari, or formula 1
racer which has no engine.
>
>
> 4) Dynamic algorithms.
> Operator and Operations can be changed on the
> fly. And can be created from scratch using basic building blocks or
> use other pluged in cypher.
Accepted, but also true in general for any encryption method -- ,I can at
any point in time chose to switch cyphering methods with any cypher I
use.( OK, I'll use IDEA today and twofish tomorow)
>
>
> 5) Can utilize throwaway algorithms.
> Yes folks: As revolutionary as it sound!!
Accepted, but also true in general for any encryption method -- ,I can at
any point in time chose to throw away my algorithim any cypher I use.(
OK, I'll never use VORTEX again after today)
>
>
> 6) Dynamic Algorithms (operators and operations)
> Algorithms can be created from scratch, and is not static.
Is this always a virtue? I can see the advantages of such a method, but I
can also see some downsides to this method as well.
>
>
> 7) Dynamic Base (symbol set)
> swappable symbols and arbitrary symbol sets.
I can also do this with any other cypher -- there is nothing that requires
cypher output be in a specific format.
>
>
> 8) Plug-And-Play engine (other cyphers can be augmentated to it)
> Yes, very modular.
True, and this would be a virtue.
>
>
> 9) Web-centric
> The engine need not reside on your client but diffused through
> the internet. Dynamic algorithms can be generated from dynamic
> content from websites.
How are the dynamic algorithims comunicated to the person who would need to
decrypt the data? are they sent as some form of plaintext, or are you using
some form of public key encryption?
>
>
> Where can I find more info about Base Encryption?
> http://www.edepot.com/phl.html
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curves encryption
Date: 12 Jul 2000 16:25:10 GMT
The P1363 password is easy to get, just ask for it, this allows them to monitor
usage.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Questions!!!!
Date: 12 Jul 2000 09:38:00 -0700
In article <[EMAIL PROTECTED]>,
Mark Wooding <[EMAIL PROTECTED]> wrote:
> George Gordon <[EMAIL PROTECTED]> wrote:
> > 1) I read in the literature that impossible differentials can be found
> > for *any* Feistel cipher for up to 5 rounds.
>
> I couldn't find any references to this 5-round attack from a few
> carefully chosen searches in Google. Can you point me at any?
Lars Knudsen has exploited this tool more than once.
See, e.g., his (FSE'99?) paper on DFC; although that is certainly
not the first time this impossible differential appeared in the literature,
if I recall correctly, that paper does include a readable discussion of
the 5-round impossible differential.
If memory serves, I think that there is an additional requirement for
the impossible differential to hold -- I think the round function must
be bijective.
------------------------------
From: Dido Sevilla <[EMAIL PROTECTED]>
Subject: Re: Limits of brute force.
Date: Thu, 13 Jul 2000 00:32:20 +0800
All of this assumes that you have a classical computer that follows the
Church-Turing model of computation. If we have a quantum computer which
we could run Grover's algorithm on, the limits change significantly.
Since Grover's algorithm allows you to perform an unordered search in
O(sqrt(N)) time, you'd have to double the number of bits in your
estimate, provided quantum computers which have an arbitrary number of
qubits are practical.
--
Rafael R. Sevilla <[EMAIL PROTECTED]> +63 (2) 4342217
ICSM-F Development Team +63 (917) 4458925
University of the Philippines Diliman
------------------------------
From: Jan Vorbrueggen <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: 12 Jul 2000 18:43:42 +0200
Paul Koning <[EMAIL PROTECTED]> writes:
> That's why CPU system buses have byte enables.
I don't think the EV6 bus has byte enables.
Jan
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Wed, 12 Jul 2000 10:48:09 -0600
I wrote:
> ... I seem
> to remember a dozen or two cycles altogether for 4 bit RC4. Also
> it was not the case that most of the states were in one long cycle.
As I think about it more, I think the way I ran the tests restricted
the possible starting states (a lot). The total number of states
for 4-bit RC4 is still quite a lot (16^2 x 16!), so I'm sure I did
not exhaustively enumerate the cycles. Still, I do remember getting
the dozen or two longish cycles; a more complete analysis could only
add to this.
JM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Random Numbers
Date: Wed, 12 Jul 2000 09:52:32 -0700
Yes, If you set an "acceptable" range as a multiple of the mod and discard
all source values out of that range it will be un-biased but it will have a
hitch in it's getalong : )
I didn't read your post clearly enough. I had a similar problem and couldn't
believe that such a simple thing was so hard to do. My problem had a high
price for skipped values and I was trying to do without. Finally had to
accept a compromise of doing a composite of two different mods on two
different values and a reject of only one value. I was hoping that you would
solve my problem and say, "Dummy, just do XYZ". It seems that the "second"
stage could be the "XYZ" but I don't understand what it gets you or how it
works. Could I impose on you to elaborate?
Thanks,
Paul
Thanks anyway.
Paul
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Tue, 11 Jul 2000 15:28:42 -0700, "Paul Pires" <[EMAIL PROTECTED]>
> wrote, in part:
>
> >Taking the last three digits is like doing mod 1000 and it seems that if
the
> >mod and the number being operated on don't have common prime factors,
then
> >it is biased. Consider that 0 to 2000 have 2 "hits" on all numbers from 0
to
> >999 but the numbers 0 to 56 have an extra hit from the 56 remainder. So
for
> >every 2056 numbers processed you could expect to see the values of 0 to
56
> >three times but could only expect to see 57 to 999 two times.
>
> >Did I misunderstand your post?
>
> Yes.
>
> You only take the last three digits if the number being operated on is
> in the range 0-1999.
>
> If it is in the range 2000-2056, it is not used to directly produce a
> number from 0-999; it is passed on to another stage. The other stage
> now converts from unbiased numbers from 0 to 57^n-1 using the same
> method.
>
> John Savard (teneerf <-)
> http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Wed, 12 Jul 2000 10:53:39 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> I am not sure what she said, but a foot per second is a very good
> approximation of C (speed of light in vacuum).
I'm sure this was a typo -- you meant "nanosecond" instead of
"second."
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: cray and time needed to attack
Date: Wed, 12 Jul 2000 11:00:34 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Which value of the speed of light in a vacuum are you using? I'm using
> the one which is 299792458 m/s, or 0.98357105643 ft/ns.
Sorry, you're absolutely correct and what I said about the exact
speed was absolutely wrong.
As I already said, this really makes no difference to the original
question, but there's no question that this particular part of what I
said was just plain wrong. I apologize.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: exports?
Date: Wed, 12 Jul 2000 12:13:46 -0400
George Gordon wrote:
>
> What's the deal with www.cryptography.org/source ? Do any of you other
> readers know ?
What do you mean?
If you look at the top level page, you'll see that it still has the
old access controls in place. Apparently it hasn't been updated to
reflect the new regulations. Then again, that might take some effort
(to verify that each item in that repository qualifies and that the
correct notice had been sent to BXA).
paul
------------------------------
From: Stephen Hui <[EMAIL PROTECTED]>
Subject: Newbie Question
Date: Wed, 12 Jul 2000 12:27:46 -0500
Hi.
I'm really, really new to cryptography and related subjects so please
excuse my ignorance....
I developed an encryption algorithm a number of years ago. It's very,
very simple (I emphasize "very, very simple"; if you know how the
algorithm works, then it's a trivial task to decrpyt the text), but I'm
just curious as to how strong it is without knowing the algorithm.
If I were to post a block of encrypted plaintext, would anyone be
interested in trying to crack it?
Thanks,
Stephen.
--
Stephen Hui, ARL:UT, Austin, Texas
Computer Terms: Programmer - A red-eyed, mumbling mammal
capable of conversing with inanimate objects.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4-- repetition length?
Date: 12 Jul 2000 18:00:57 GMT
In <[EMAIL PROTECTED]> John Myre <[EMAIL PROTECTED]> writes:
]I wrote:
]> ... I seem
]> to remember a dozen or two cycles altogether for 4 bit RC4. Also
]> it was not the case that most of the states were in one long cycle.
]As I think about it more, I think the way I ran the tests restricted
]the possible starting states (a lot). The total number of states
]for 4-bit RC4 is still quite a lot (16^2 x 16!), so I'm sure I did
]not exhaustively enumerate the cycles. Still, I do remember getting
]the dozen or two longish cycles; a more complete analysis could only
]add to this.
Since 16^2*16!= 10^16, your cycles must all have been much much shorter
than that!. Has any work been done on analysing the cycles of RC4? Is
there some way of changing it to ensure that there is only one cylce of
max length?
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: 3DES Bruce Schneier, Applied Crypto CD?
Date: 12 Jul 2000 18:02:59 GMT
In <8kgg0m$hlj$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
]I am pretty new to Cryptography,
]I have purchased Source Code CD from Bruce anyone used 3DES alogorthem
]and implemented?
]I could not locate any WORKING program with main() function from the CD
]for 3DES for Linux/FreeBSD?
All of them are going to library routines, not self contained programs.
You either need to write you own main() to call the library, or get Eric
Young's libdes, which does include a self contained program for encoding
and decoding.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Random Numbers
Date: 12 Jul 2000 18:06:27 GMT
In <8kgov0$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Guy Macon) writes:
]David Hyde wrote:
]>Guy Macon wrote:
]>>
]>> Consider the case if you sample at. say 10 Gigasamples/second.
]>> Would the bits produced be independent of each other?
]>
]>Depends on the bandwidth of the white noise source. I'm sampling at a very
]>much lower rate then the highest frequency produced by the bandlimited white
]>noise.
]And as you transition between 10GSS and your much lower rate, does the
]Corollation between adjacent bits drop off smoothly or all at once?
]At your sample speed, is the corolation zero or just very very small?
This is of course an open question for any physical inplimentation. For
example, consider some LC circuit in there ( or an RC with the diode
acting as an amplifier) which oscillates at say 1MHz. This will produce
correlations in the output on the order of 1micro sec. Getting rid of
such correlations means you must understand the physics of the generator
extremely well.
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Public/Private Key crypting
Date: Wed, 12 Jul 2000 10:54:32 -0700
> Did you notice that the OP wanted the two encryptions (or decryptions)
> to commute?
Oops, my bad.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Newbie Question
Date: Wed, 12 Jul 2000 11:11:42 -0700
Actually this is in the FAQ. Basically the general concensus is that if your
program needs to remain secure to make the cipher secure, then your cipher
is not secure. Your software will be broken (see any warez site for
reference), your code will be known, and your security will never have
existed. So we would prefer you don't post your ciphertect here unless you
have an algorithm to go with it.
Joe
"Stephen Hui" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi.
>
> I'm really, really new to cryptography and related subjects so please
> excuse my ignorance....
>
> I developed an encryption algorithm a number of years ago. It's very,
> very simple (I emphasize "very, very simple"; if you know how the
> algorithm works, then it's a trivial task to decrpyt the text), but I'm
> just curious as to how strong it is without knowing the algorithm.
>
> If I were to post a block of encrypted plaintext, would anyone be
> interested in trying to crack it?
>
> Thanks,
> Stephen.
>
> --
> Stephen Hui, ARL:UT, Austin, Texas
>
> Computer Terms: Programmer - A red-eyed, mumbling mammal
> capable of conversing with inanimate objects.
------------------------------
From: Helger Lipmaa <[EMAIL PROTECTED]>
Subject: Re: Questions!!!!
Date: Wed, 12 Jul 2000 20:18:35 +0300
"David A. Wagner" wrote:
> In article <[EMAIL PROTECTED]>,
> Mark Wooding <[EMAIL PROTECTED]> wrote:
> > George Gordon <[EMAIL PROTECTED]> wrote:
> > > 1) I read in the literature that impossible differentials can be found
> > > for *any* Feistel cipher for up to 5 rounds.
> >
> > I couldn't find any references to this 5-round attack from a few
> > carefully chosen searches in Google. Can you point me at any?
>
> Lars Knudsen has exploited this tool more than once.
> See, e.g., his (FSE'99?) paper on DFC; although that is certainly
> not the first time this impossible differential appeared in the literature,
> if I recall correctly, that paper does include a readable discussion of
> the 5-round impossible differential.
Lars R. Knudsen, ``DEAL - A 128-bit Block
Cipher" (http://www.ii.uib.no/~larsr/papers/deal.ps) is the
(I believe) historically first reference. See Proposition 1 there.
Helger Lipmaa
http://www.tcm.hut.fi/~helger
>
>
> If memory serves, I think that there is an additional requirement for
> the impossible differential to hold -- I think the round function must
> be bijective.
------------------------------
From: "Thomas Womack" <[EMAIL PROTECTED]>
Crossposted-To: comp.arch
Subject: Re: Proposal of some processor instructions for cryptographical applications
Date: Tue, 11 Jul 2000 21:05:49 +0100
"Dennis Yelle" <[EMAIL PROTECTED]> wrote
> The weakness seems to be that there is only one operation
> that moves bits from the left half to the right half, or
> vice versa.
That's familiar; it sounds like the same problem I had when trying to
construct sorting networks. I reckoned that you could do something clever
with MMX shuffles, PMIN and PMAX operations, and sort sets of eight shorts
with 16-bit data attached extremely quickly; it may well be possible, but
I'm not that clever. Not to mention that nobody actually wants to sort
shorts with 16-bit data attached.
Tom
------------------------------
** 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 (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
