Cryptography-Digest Digest #559, Volume #14 Thu, 7 Jun 01 23:13:01 EDT
Contents:
Re: Simple C crypto ("Tom St Denis")
Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
Re: Alice and Bob Speak MooJoo ("Tom St Denis")
Re: Brute-forcing RC4 ("Scott Fluhrer")
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: Brute-forcing RC4 ("Tom St Denis")
Re: Simple C crypto ("Boyd Roberts")
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: CBC variant ("Scott Fluhrer")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Brute-forcing RC4 ("Scott Fluhrer")
Re: Brute-forcing RC4 ("Tom St Denis")
Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
Re: Simple C crypto ("Dirk Bruere")
Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large Primes
(sisi jojo)
Re: Simple C crypto ("Dirk Bruere")
Re: Brute-forcing RC4 ("Scott Fluhrer")
Re: Simple C crypto ("Tom St Denis")
Re: Any Informed Opinions? ("Dirk Bruere")
Re: Simple C crypto ("Dirk Bruere")
Re: Simple C crypto ("Tom St Denis")
----------------------------------------------------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 08 Jun 2001 00:56:36 GMT
"Dirk Bruere" <[EMAIL PROTECTED]> wrote in message
news:6OUT6.19530$[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:xITT6.52725$[EMAIL PROTECTED]...
> >
> > > The requirement is for text comments (for example) to be written to a
> file
> > > along with data. We simply don't want people to get into the file to
> read
> > > and/or alter the text. We're not talking about professional hackers or
> the
> > > NSA, just (say) lab technicians who use the equipment. Detecting
> > alteration
> > > of the text is something else.
>
> > > So, no freeware solution to such a simple problem?
>
> > There are tons of public domain crypto tools (tools = algorithms).
> Whether
> > your a competent enough cryptographer to use them is another question.
>
> I don't have to be a competent crypographer if someone else has done the
> work.
> I use other peoples programs to do jobs so I don't have to write them
> myself, or even know how they work. Am I supposed to be able to code .jpg
> before I can embed a picture viewer?
There is more to crypto then just using a cipher. just like there is more
to a codec then a library to output jpg. However, unlike outputting a jpg,
errors in crypto can be more than just annoying. They can be fatal errors.
For example, if you default to 0.99 quality in your JPG library that's
annoying. If you default to 16-bit symmetric keys that's useless!
> > Also if your application that you distribute can read these "magically
> > encoded files" then so can anyone else. This is a re-hash of the
> > CSS/SDMI/etc designs. Here's a tip, they don't work.
>
> The files are output from a data logger, we just don't want people
casually
> changing the data.
>
> I rather doubt the ability and motivation of normal users to reverse
> engineer the application to determine the crypo method in order to change
> the comments in a file. If they are that keen then they will have faked
the
> whole thing from start to finish. The algorithm is not in a file viewer
they
> will have access to, unless, of course, they do that reverse engineering.
> They can encode a comment (if it is theirs), but not decode anything.
>
> All I am looking for is something that will require a few hours of work by
a
> competent engineer with the right tools to break. That is the level of
> deterrence required.
The problem with this (as many and espesicially Schneier have pointed out)
is that it only takes ONE person to break your program ONCE. Then it's all
down hill. Who cares if it takes them 3 days. Once they complete the task
ONCE they will FOREVER.
> > If you application is based on secrets like passwords or what have not
> just
> > use a cipher like Blowfish in CTR mode to encode the files. Alterations
> > will show up in the plaintext but if you need more assurance append a
hash
> > of the pre-image to the plaintext. That should stop all attacks on "the
> > math". At that point it's upto physical and password security.
>
> Done a search on Blowfish, but could not find any code. If its more than
> about 100 lines of C then I'm not interested. I just need a key of length
N,
> and two functions
>
> #include "encryption.h"
> CString Encrypt( Cstring )
> CString Decrypt( Cstring )
>
> something as simple as that to drop into existing code.
Then don't ask here. If you are not willing to do the job right why are you
asking others for help?
Tom
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 07 Jun 2001 20:58:33 -0400
Joseph Ashwood wrote:
> required a few years. To prove this consider the fact that a human baby
> learns to speak without having prior knowledge of any language
Babies learn their first language by ostensible defnition. The point
finger. There is no other way to learn one's first language.
That is why the sci fi movies of the 1950's used to drive me nuts.
The Visiting Alien would say how he learned our language from
* radio * broadcasts! T.V. maybe. Radio never.
Bob Kolker
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Fri, 08 Jun 2001 01:03:53 GMT
"Robert J. Kolker" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Joseph Ashwood wrote:
>
> > required a few years. To prove this consider the fact that a human baby
> > learns to speak without having prior knowledge of any language
>
> Babies learn their first language by ostensible defnition. The point
> finger. There is no other way to learn one's first language.
>
> That is why the sci fi movies of the 1950's used to drive me nuts.
> The Visiting Alien would say how he learned our language from
> * radio * broadcasts! T.V. maybe. Radio never.
Not that I have a clue about psychology or whatever this ties too but...
How would a blind person learn to speak?
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Thu, 7 Jun 2001 17:59:06 -0700
Ichinin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Scott Fluhrer wrote:
> >
> > Ichinin <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Hi.
> > >
> > > S Degen wrote:
> > > >
> > > > Howmuch time would it take to brute-force a 40 bit RC4 key?
(Ofcourse
> > > > depending on the processor-speed, but lets say a PIII 500)
> > >
> > > Don't really know about a P3/500, but compare
> > >
> > > In my home lab i did a brute force estimate once on RC4
> > > (including all key setups and guessing).
> > >
> > > Using:
> > >
> > > 1 x P1/133 acting as a job server
> > > 1 x P2/266 - slave client
> > > 1 x AMD K6/350 - slave client
> > > 1 x P3/700 (Bus can be clocked to 117 Mhz; == ~819 Mhz)
> > >
> > > ..i estimated that with a C++ plugin for each slave
> > > client, i could brute force a 2^40 key in roughly 180
> > > days.
> > >
> > > The computing power could be compared to 2 to 2.5 P3/500,
> > > so, if my guess is correct, around 180 x 2 (or 2.5) days.
> >
> > I haven't actually run any expirements, but that doesn't sound right to
me.
> > An iteration of the RC4 key setup takes 7 operations by my count
(counting
> > loads/stores/adds-mod-256 as one operation), and is somewhat
parallizable.
> > It happens 256 times for each key, and then there are a few operations
to
> > generate the first byte of keystream, test it, and then step to the next
> > key. All this (because of the parallizability) should be quite doable
in
> > 7*256 cycles or 3.5usec, and possibily half that. A complete keysearch
> > should then take 3.5 * 2^40 = 4 * 10^12 usec = 44 days, with the
expected
> > time being half that.
> >
> > Were you using any fancy C++ classes in the key setup? That'd get in
the
> > way.
>
> Nope, a vanilla RC4 implementation in VC++.
> Could be the checking algorithm; i.e. step
> through the decrypted message; is it alpha
> numerical only?
Actually, what you should do is generate the first byte of RC4 output for
the key under test, and check if it happens to be the xor of the first byte
of plaintext and the first byte of ciphertext. If it isn't (and it won't be
99+% of the time), you immediately skip to the next key.
--
poncho
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 21:19:52 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>[ BICOM increasing likelihood of false decryptions ]
>: You don't have any idea what the net effect will be.
>
> So you falsely claim.
I apologize! I just didn't realize you'd got a proof. Where is it published?
Or is it on your web page? Or would you post it here? If it's not too
terribly long, you can email it to me. I wait with interest.
Len.
--
Frugal Tip #20:
Take hostages.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Fri, 08 Jun 2001 01:22:58 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9fp8qh$o1n$[EMAIL PROTECTED]...
> Actually, what you should do is generate the first byte of RC4 output for
> the key under test, and check if it happens to be the xor of the first
byte
> of plaintext and the first byte of ciphertext. If it isn't (and it won't
be
> 99+% of the time), you immediately skip to the next key.
More precisely won't it be 255/256 of the time?
Also I would like to meet the person who first claimed 7 bytes per cycle.
How the heck did they do that?
Tom
------------------------------
From: "Boyd Roberts" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 8 Jun 2001 03:24:32 +0200
"Dirk Bruere" <[EMAIL PROTECTED]> a écrit dans le message news:
6OUT6.19530$[EMAIL PROTECTED]
> The files are output from a data logger, we just don't want people casually
> changing the data.
write it onto write-once media.
or just grab DES. there are a zillion about:
http://www.planete.net/~boyd/code/des.msg
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 07 Jun 2001 21:26:02 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>:> The fish are plausible plaintexts. The tank represents files
>:> sorted by size. Files at the end of the tank are shorter than ones
>:> further away. The directional swimming of the fish represents
>:> compression.
>
>: GLORY, GLORY HALELUJAH! NOW I GET IT! Please, please, write this up and
>: submit it to the Acta Mathematica...
>
> I assume you didn't understand :-( I figure that makes you a lost cause.
Don't go easy on me--give me the full-bore mathematical proof. If you
like, we can trade: I'll send you a copy of my PhD thesis, and you send
me a copy of your actual proof.
>:> Did you miss my 129 bit message?
>
>: If that's not the only message you send, then we're NOT dealing with
>: only 129 bits; we're dealing with all the bits you encrypted with that
>: key.
>
> No - not if there are multiple messages and key per message.
If there is a separate key per message, you do realize that you have
a serious key distribution problem, don't you?
Hint: That's why one-time-pads aren't used for everything. It's not
because we love a challenge, or because we think perfect secrecy is
unsportsmanlike.
Len.
--
Don't ask the barber whether you need a haircut.
-- Warren Buffett, 1982
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: CBC variant
Date: Thu, 7 Jun 2001 18:14:55 -0700
John Savard <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 7 Jun 2001 13:07:09 -0400, <[EMAIL PROTECTED]> wrote, in
> part:
>
> >As stated, this needs just two xors and one encryption (same key) in
> >addition to regular CBC. Can anyone find faults in it? If worth
> >anything, use freely ;)
>
> Actually, I think you have come up with something brilliant, even so.
>
> Let's suppose we tried to use two different keys.
>
> One big problem with increasing the strength of a block cipher is that
> most simple double-DES modes art no stronger than single-DES.
>
> Let's suppose, for example, that this double-DES variant of CBC is
> used:
>
> encrypt the previous ciphertext block with key A.
>
> XOR the result with the current plaintext block.
> Encrypt with key B.
> XOR the previous encryption result in again.
(Actually, I really don't see the point in the last step...)
>
> With chosen plaintext, one can still mount a differential attack on
> the encryption with key B. It may need to be adaptive and use the
> birthday attack, but it's still possible.
Actually, a standard meet-in-the-middle approach (with a few known plaintext
blocks) breaks this. The encryption algorithm is:
C_n = C_{n-1} ^ E_b( P_n ^ E_a(C_{n-1}) )
or
D_b( C_n ^ C_{n-1} ) = P_n ^ E_a(C_{n-1})
So, given a known set (P_n, C_{n-1}, C_n), we just list the possible values
for D_b(C_n ^ C_{n-1} ) and P_n ^ E_a(C_{n-1}) for all possible keys a and
b, and look for collisions. This (obviously) takes a lot of memory, but no
more than the standard approach to break standard double-encryption. This
also assumes that the attacker can cycle from the entire keyspace of one of
the keys -- but if he couldn't, what's wrong with standard CBC?
>
> To fix this, what one would like is for the quantity being XORed in,
> before and after the encryption with key B, to vary with each block in
> a completely unknown fashion.
>
> Since key A is unknown, and all we are looking for is to make the
> strength of that cipher a full participant, one way of doing that
> would be this:
>
> Have a counter, with a starting value and increment that are both
> secret and vary with each message. XOR the counter with the previous
> plaintext before encrypting with key A.
And continue with the described approach, I assume? Then, if k is the
number of bits of within key, and b is the number of bits within the block,
the above approach breaks it in 2^{min(2*k,k+b)} effort -- significantly
better. There may be another weakness, but it doesn't come immediately to
mind.
>
> Of course, the counter has to be randomized anew if the message is
> longer than 2^64 blocks. (Actually, after 2^63 blocks, there's a known
> difference, so one has to use a slightly better PRNG instead of a
> plain counter.)
>
> Monalphabetic byte substitution is another nice way to stop
> differential attacks, and fast enough. But this is a useful spot to
> hide a fast stream cipher.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Fri, 08 Jun 2001 01:45:21 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tim Tyler <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> >:> The fish are plausible plaintexts. The tank represents files
> >:> sorted by size. Files at the end of the tank are shorter than ones
> >:> further away. The directional swimming of the fish represents
> >:> compression.
> >
> >: GLORY, GLORY HALELUJAH! NOW I GET IT! Please, please, write this up and
> >: submit it to the Acta Mathematica...
> >
> > I assume you didn't understand :-( I figure that makes you a lost cause.
>
> Don't go easy on me--give me the full-bore mathematical proof. If you
> like, we can trade: I'll send you a copy of my PhD thesis, and you send
> me a copy of your actual proof.
What's your thesis on? Mind sending me a copy?
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Thu, 7 Jun 2001 18:32:19 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:SNVT6.54489$[EMAIL PROTECTED]...
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:9fp8qh$o1n$[EMAIL PROTECTED]...
> > Actually, what you should do is generate the first byte of RC4 output
for
> > the key under test, and check if it happens to be the xor of the first
> byte
> > of plaintext and the first byte of ciphertext. If it isn't (and it
won't
> be
> > 99+% of the time), you immediately skip to the next key.
>
> More precisely won't it be 255/256 of the time?
Yes.
>
> Also I would like to meet the person who first claimed 7 bytes per cycle.
> How the heck did they do that?
I suspect it was the magic of a typo (and I hope it wasn't me that claimed
it).
--
poncho
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Fri, 08 Jun 2001 02:01:47 GMT
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:9fpao7$8bj$[EMAIL PROTECTED]...
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:SNVT6.54489$[EMAIL PROTECTED]...
> >
> > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > news:9fp8qh$o1n$[EMAIL PROTECTED]...
> > > Actually, what you should do is generate the first byte of RC4 output
> for
> > > the key under test, and check if it happens to be the xor of the first
> > byte
> > > of plaintext and the first byte of ciphertext. If it isn't (and it
> won't
> > be
> > > 99+% of the time), you immediately skip to the next key.
> >
> > More precisely won't it be 255/256 of the time?
> Yes.
aha, my math is not failing me :-)
> > Also I would like to meet the person who first claimed 7 bytes per
cycle.
> > How the heck did they do that?
> I suspect it was the magic of a typo (and I hope it wasn't me that claimed
> it).
I love these magic cycle counts people get. I don't want to say this but I
think some cryptographers just fluff their results because they know nobody
is likely to actually verify their claims.
Tom
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 07 Jun 2001 22:08:56 -0400
Tom St Denis wrote:
>
> How would a blind person learn to speak?
Touch. You teach a blind baby what the word
"ball" means by placing a ball in his hand. Ditto
for the word "round". No point in trying to teach
color as it cannot be detected by touch, but hot
and cold can.
The long and skinny is that to learn a language
(particularly your first) you need * referrents *.
Just hearing words (noises) or seeing symbols
conveys no meaning in the absence of a direct
referrent (the thing referred to) or indirect referrent,
a statement about t he thing in a known language.
This is why the code talkers were a complete
success. The enemy had no referrents either
direct or indirect, so they were left clueless.
Bob Kolker
------------------------------
From: "Dirk Bruere" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 8 Jun 2001 03:10:04 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8pVT6.54305$[EMAIL PROTECTED]...
>
> > All I am looking for is something that will require a few hours of work
by
> a
> > competent engineer with the right tools to break. That is the level of
> > deterrence required.
> The problem with this (as many and espesicially Schneier have pointed out)
> is that it only takes ONE person to break your program ONCE. Then it's
all
> down hill. Who cares if it takes them 3 days. Once they complete the
task
> ONCE they will FOREVER.
That is not a major worry.
> > about 100 lines of C then I'm not interested. I just need a key of
length
> N,
> > and two functions
> >
> > #include "encryption.h"
> > CString Encrypt( Cstring )
> > CString Decrypt( Cstring )
> >
> > something as simple as that to drop into existing code.
> Then don't ask here. If you are not willing to do the job right why are
you
> asking others for help?
Because there are degrees of doing the job at all.
I don't need the all-bells-and-whistles best.
Dirk
------------------------------
From: [EMAIL PROTECTED] (sisi jojo)
Subject: Re: Help with Comparison Of Complexity of Discrete Logs, Knapsack, and Large
Primes
Date: 7 Jun 2001 19:13:27 -0700
> Joseph Ashwood <[EMAIL PROTECTED]> wrote:
>
> > Take a simpler problem 1+1=2, everyone learns that in 1st grade (some
> > earlier, some a little later), but it takes a doctorate in
> > mathematics, and a few hundred pages of very intricate math to prove
> > it without assuming things.
>
> I don't have such a doctorate, but... What other meaning of the symbol
> `2' did you have in mind that might conflict with it being the value
> formed by adding the multiplicative identity of the ring of integers to
> itself? (Proof that 1 + 1 is not equal to 0 or 1, the two integers
> actually named in the integer axioms, is immediate from the properties
> of the ordering on integers, so a separate symbol is justified.)
>
> -- [mdw]
Actually we had to prove 1+1=2. I was a freshman. It was the first math
assignment I had in Univ. The course was proving technique. Back then I
thought Univ edu was very weird.
--Sisi
------------------------------
From: "Dirk Bruere" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 8 Jun 2001 03:17:29 +0100
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:ewmPUO77AHA.88@cpmsnbbsa09...
>
> > > information than that I'd suggest you offer a respected person
> > > cryptographically a sum of money for consulting.
> > Well, that's just not going to happen.
> Sorry, my personal policy is that I do solid consulting for free if the
> result will be free, I charge if you will charge.
Let's see now...
I've got a time budget of about $50 to spend on this, including coding and
code integration.
You're welcome to a 10% finders fee for pointing me to the functions I
listed.
Maybe that gives you some idea of the importance this holds in the overall
scheme of a $200k project.
> > So, no freeware solution to such a simple problem?
> There are plenty of them; FEAL, Rijndael, Twofish, Serpent, Blowfish,
3DES,
> DES, RSA, ElGamal, RC2, ARC4, SHACAL, MacGuffin, Leviathan, CAST, MARS,
> SKIPJACK just to name a few off the top of my head (by the way several of
Thanks.
> the ones I listed are weak, one of them almost as weak as your idea). Of
> course if you'd like to figure out which one you should use that's a much
> more difficult question.
Not really.
It's the one that is easiest to code and/or is already coded in C on the
net.
Dirk
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Thu, 7 Jun 2001 19:06:49 -0700
S Degen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
> depending on the processor-speed, but lets say a PIII 500)
>
> This is the case:
> You have a 128 bit (ASCII) text, and the encyphered version of it. This
> version is encyphered with a 64 bit secret key, but of those 64 bits, 24
> bits are known. (Leaving 40 unkown bits)
>
> I would like to know how long it would approximately take to calculate
> the 40 bit secret key.
Would you mind very much if I asked what system you were attacking?
--
poncho
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 08 Jun 2001 02:22:47 GMT
"Dirk Bruere" <[EMAIL PROTECTED]> wrote in message
news:KqWT6.20007$[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:8pVT6.54305$[EMAIL PROTECTED]...
> >
> > > All I am looking for is something that will require a few hours of
work
> by
> > a
> > > competent engineer with the right tools to break. That is the level of
> > > deterrence required.
>
> > The problem with this (as many and espesicially Schneier have pointed
out)
> > is that it only takes ONE person to break your program ONCE. Then it's
> all
> > down hill. Who cares if it takes them 3 days. Once they complete the
> task
> > ONCE they will FOREVER.
>
> That is not a major worry.
Then what is?
>
> > > about 100 lines of C then I'm not interested. I just need a key of
> length
> > N,
> > > and two functions
> > >
> > > #include "encryption.h"
> > > CString Encrypt( Cstring )
> > > CString Decrypt( Cstring )
> > >
> > > something as simple as that to drop into existing code.
>
> > Then don't ask here. If you are not willing to do the job right why are
> you
> > asking others for help?
>
> Because there are degrees of doing the job at all.
> I don't need the all-bells-and-whistles best.
I would hate to have you as a heart surgeon :-)
Why even bother with crypto? Just xor the file with 0xAA.
Tom
------------------------------
From: "Dirk Bruere" <[EMAIL PROTECTED]>
Subject: Re: Any Informed Opinions?
Date: Fri, 8 Jun 2001 03:24:50 +0100
"Jeffrey Walton" <[EMAIL PROTECTED]> wrote in message
news:3b2016d4$0$[EMAIL PROTECTED]...
> Quantum cryptography has been demonstrated at AT&T labs (is the lab
> correct?) upto a distance of about 15 km in a fibre. This number has
> probably improved. Bennet and Brassard built the protoype. See the
> section Technical Limits in Quantum Cryptography in
> http://www.aro.ncren.net/phys/proceed.htm for a more complete treatment
> (but somewhat out of date). A recent but less technical article can be
> found at http://www.wired.com/news/privacy/0,1848,40969,00.html
> The computers that will factor and solve DLP are still in their infancy.
So we are told.
So far the max I have heard of is a 7 qubit demo. Useful machines probably
start at around the 50qubit mark, and we are officially a long way from
that. However, who knows what a billion dollars of NSA money might have come
up with?
> From what I understand, they have been demonstarted; but only exist for
> less than nanoseconds. I don't have a reference for the demonstartion.
> I think it was read in a journal.
A few nS is enough if it completes the calculation you need.
> It does not appear a quantum computer will break a quantum cryptosystem.
There is a 'no cloning' theorem in QM which makes it secure. However, it is
known that QM is not the last word in desriptions of nature, especially
where the crucial 'measurement process' (collapse of the wave function) is
concerned. This is at the heart of quantum computing and is not understood,
despite plenty of speculation, incluing consciousness as the agent.
> A quantum computer will probably break all classical computer based
> cryptosystems. Mollin, An Introduction to Cryptography, p.267.
There is also speculation that QCs will follow 'Moores Law', although its
rather early to tell. This means that every two years or so the number of
qubits will double. If so most cypher systems will be insecure within this
decade.
Dirk
------------------------------
From: "Dirk Bruere" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 8 Jun 2001 03:35:40 +0100
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:XFWT6.54813$[EMAIL PROTECTED]...
> > > down hill. Who cares if it takes them 3 days. Once they complete the
> > task
> > > ONCE they will FOREVER.
> >
> > That is not a major worry.
>
> Then what is?
Someone fiddling with a file on a computer because they're bored for 10min?
> > > > about 100 lines of C then I'm not interested. I just need a key of
> > length
> > > N,
> > > > and two functions
> > > >
> > > > #include "encryption.h"
> > > > CString Encrypt( Cstring )
> > > > CString Decrypt( Cstring )
> > > >
> > > > something as simple as that to drop into existing code.
> >
> > > Then don't ask here. If you are not willing to do the job right why
are
> > you
> > > asking others for help?
> > Because there are degrees of doing the job at all.
> > I don't need the all-bells-and-whistles best.
> I would hate to have you as a heart surgeon :-)
The job is more akin to cutting your toe nails:-)
> Why even bother with crypto? Just xor the file with 0xAA.
Quite likely a variant of that will be used, unless there is some
almost-as-simple and stronger alternative.
Hence my inquiry.
Dirk
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 08 Jun 2001 02:53:08 GMT
"Dirk Bruere" <[EMAIL PROTECTED]> wrote in message
news:JOWT6.20142$[EMAIL PROTECTED]...
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:XFWT6.54813$[EMAIL PROTECTED]...
> > > > down hill. Who cares if it takes them 3 days. Once they complete
the
> > > task
> > > > ONCE they will FOREVER.
> > >
> > > That is not a major worry.
> >
> > Then what is?
>
> Someone fiddling with a file on a computer because they're bored for
10min?
And if they are lucky and happend to know how to make a website?
> > > > > about 100 lines of C then I'm not interested. I just need a key of
> > > length
> > > > N,
> > > > > and two functions
> > > > >
> > > > > #include "encryption.h"
> > > > > CString Encrypt( Cstring )
> > > > > CString Decrypt( Cstring )
> > > > >
> > > > > something as simple as that to drop into existing code.
> > >
> > > > Then don't ask here. If you are not willing to do the job right why
> are
> > > you
> > > > asking others for help?
>
> > > Because there are degrees of doing the job at all.
> > > I don't need the all-bells-and-whistles best.
>
> > I would hate to have you as a heart surgeon :-)
>
> The job is more akin to cutting your toe nails:-)
>
> > Why even bother with crypto? Just xor the file with 0xAA.
>
> Quite likely a variant of that will be used, unless there is some
> almost-as-simple and stronger alternative.
> Hence my inquiry.
Well if you find something patent it and sell it to the MPAA and RIAA. You
will make literally millions!
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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
