Cryptography-Digest Digest #527, Volume #11 Tue, 11 Apr 00 00:13:01 EDT
Contents:
Re: Is AES necessary? (BYRDFLOWER)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (lordcow77)
Re: Is AES necessary? (Tom St Denis)
Re: Encode Book? (lordcow77)
Re: Mersenne RNG, RNG questions (lordcow77)
Re: Crypto for embeded platforms? (Paul Rubin)
Re: Crypto for embeded platforms? (Paul Rubin)
Re: Encode Book? (Tom St Denis)
Looking for crypto short course or workshop ("Kim J.-H.")
Re: Encode Book? (Paul Rubin)
Re: Crypto for embeded platforms? (Tom St Denis)
yet another perm poly idea (Tom St Denis)
Re: yet another perm poly idea (Tom St Denis)
Re: Crypto for embeded platforms? (Paul Rubin)
Re: new Echelon article ([EMAIL PROTECTED])
Re: Factoring Large Numbers - I think I figured it out! ([EMAIL PROTECTED])
Re: Q: Entropy (Bryan Olson)
Re: 2048 Bit Encryption? ([EMAIL PROTECTED])
Re: DNA steganography ("John A. Malley")
Re: Checksum for digits ("Lyalc")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (BYRDFLOWER)
Subject: Re: Is AES necessary?
Date: 11 Apr 2000 02:17:42 GMT
okay i see you must deal with AES I know its a advanced encryption standard
what is it really in layman's term.. And if you know that what is a Message
Authentication Code (MAC). I realize i am asking alot of question I am in
school and can't seem to fine this in any of my text.
------------------------------
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
From: lordcow77 <[EMAIL PROTECTED]>
Date: Mon, 10 Apr 2000 19:19:28 -0700
In article <[EMAIL PROTECTED]>, DMc
<[EMAIL PROTECTED]> wrote:
>>> For instance, the original problem I gave A.S.S requires
>>>calculating 16 807 ^ 1 073 741 824. That calculation result is
>>>way beyond the limits of an "infinite" digits program I have.
>[lordcow77 snipped the most important part of this paragraph]
>>
>>The result of a modular exponentiation can be calculated easily
>>using a square and multiply method, reducing at each stage.
>>
>For us ordinary interested persons, be so kind as to actually
do this
>easy calculation at least once so we can all benefit from your
>expertise. After all, you say it is easy.
>
Despite my hesitation at doing what should be obvious homework
problems for others, I will correct your inaccurate statement so
that others are not mislead by your confidently wrong banter.
Obtaining the (n+j)th iterate of a MLCG given:
x_(n+j)=(a^j*x_n)mod m
or, more generally
x_(n+j)=(a^j*x_n+c(a^j-1)/(a-1))mod m
which reduces to the first equation when c=0
x_1073741824=(16807^1073741824*x_1)mod 2147483647
x_1=1
after a trivial calculation
x_1073741824=2147466840
I would encourage you to develop reading comprehension skills
better in the future. Just having Knuth on your bookshelf
doesn't neccessarily make you a mathematician or computer
scientist...
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Tue, 11 Apr 2000 02:28:11 GMT
BYRDFLOWER wrote:
>
> okay i see you must deal with AES I know its a advanced encryption standard
> what is it really in layman's term.. And if you know that what is a Message
> Authentication Code (MAC). I realize i am asking alot of question I am in
> school and can't seem to fine this in any of my text.
Um I would suggest getting new texts :)
AES is the Advanced Encryption Standard designed to replace the older
Data Encryption Standard (DEA-1). DEA-1 is basically a symmetric cipher
(meaning the same private key will encrypt and decrypt) with a *small*
56-bit key, and a 64-bit block size. That means it encrypts 64 bits (8
bytes) at a time, and there are only 2^56 possible mappings of input to
output.
AES on the other hand is a symmetric cipher [aswell] but with a 128, 192
and 256 bit key support [you can use either] and a 128-bit block size.
There are currently five AES finalists [MARS, RC6, Twofish, Serpent and
Rijndael] all of which are well designed [speed, size and security wise]
ciphers. They are all designed to be much faster, efficient and securer
then the aging DEA-1.
*NB: I call the 56-bit key small since anyone with enough dedication
can find it in a relatively short period of time. To be some resistant
to brute force, your key should be at least 70 or so bits, but I would
start at 128 bits just to keep out of reach [for a long while].
Tom
------------------------------
Subject: Re: Encode Book?
From: lordcow77 <[EMAIL PROTECTED]>
Date: Mon, 10 Apr 2000 19:27:30 -0700
In article <[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>Pretty much ya, plus you never see anything *new* from her. If
she
>wants to get known [or have her side of the story] she should
have a
>webpage or talk in sci.crypt.
>
She's not milking her fame at all; I believe this topic was
discussed viz a viz "Sophie Germain primes." The sad truth is
that the mathematics profession has a paucity of females at the
highest levels of it. When someone her age discovers such an
interesting algorithm, but especially a female, it is only
natural that the media would choose to jump over it. Besides,
strictly speaking there's nothing wrong with choosing to write a
book about her involvement in the whole situation; it's done all
the time in other areas. Tom, what precisely do you expect her
to invent or to prove next? A proof of the Extended Riemann
Hypothesis? A proof of the ABC conjecture? A proof that P!=NP? A
proof that RSAP is polytime equivalent to factoring? Suggesting
that not posting on sci.crypt implies some lack of character or
ability is certinaly presumptous. Sci.crypt has about ten
reasonably competent regular posters, with Douglas Gwyn, Jim
Gilogy, and Bob Silverman being about the most prominent.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
Subject: Re: Mersenne RNG, RNG questions
From: lordcow77 <[EMAIL PROTECTED]>
Date: Mon, 10 Apr 2000 19:29:13 -0700
In article <[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>
>>It's not on the rogers@home news server yet, or is the group
not created
>yet?
>
A newsgroup is not exactly created out of thin air. After the
vote to create the newsgroup passes (which, I believe,
sci.crypt.random-numbers did) different news adminstrators must
add the newsgroup to their routing and acceptance tables so that
messages can propagate from the group and the postings can be
stored for retrival on your news server. This process is, shall
we say, less than instant.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Crypto for embeded platforms?
Date: 11 Apr 2000 02:35:10 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>> 4k is too large, keep it under 1k, preferably way under.
>
>Well the goal is to write the lib first, then if it's popular start asm
>ports of the source. So right now I would target it to things like an
>8051 with say 8kb of codespace... Then with the asm ver it could be 1kb
>or so. I have experience writing for embeded platforms [I did a VM for
>a cpu on a AVR8015 in 512 words of code...]
OK.
>> >1. A symmetric cipher
>>
>> OK. If you're limited to a single block cipher, Skipjack may be the
>> best choice, because of very low RAM requirements. You might also
>> want to add a stream cipher or two. (#1 = RC4, #2 = something using
>> less ram, if you can find one).
>
>Well what about TEA? other then the shifting, etc... it uses very
>little ram. I could just replace the symmetric block cipher with rc4 or
>something [my secure lagged fibonacci generator ? :)]
TEA needs more ram than Skipjack but probably less code space.
It might be good to offer both as options. That doesn't count against
your total code consumption since the user normally will only pick one.
>> >2. A hash function (sha-1?)
>>
>> This is kind of problematic but yes, sha-1 is probably the best choice.
>> MD2 is probably the most straightforward to implement on an 8-bit cpu
>> and needs less ram than sha-1. You might use some hashing scheme
>> based on the block cipher.
>
>Well the output has to be at least 160 bits to be secure I would think.
>So md2 is out, unless it's modifyable (= bad) to output more.
Depends on what you want to be secure against. These low-end embedded
things might not have such intense security needs in many cases anyway.
Md2 output is 128 bits. Md2 has other problems unrelated to its output
lenngth, though.
>> >3. A rng [based on the hash]
>>
>> Might be overkill.
>
>It's not hard todo at all, say 30 lines of code at the most...
Yes, but slow and memory hungry.
>I am using Micro-C (from DDS, Disclaimer: I am in no way affiliated
>with DDS...) because the author was generous enough to share his tools
>with me. So I could test my code on a 8051 (using his simulator) and I
>could compile it for a 8051/avr/6809/etc...
>
>Basically I want to start in c and port to asm. I should be able to
>code it in C in under 4kb no prob.
>
>So RC4 + SHA-1 + RNG = lib ?
I think you need to add a block cipher. Also, rc4 uses way too much
ram for many applications. I just don't know what's around in good
low-ram stream ciphers. You could use a block cipher in counter mode,
but that would be pretty slow.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Crypto for embeded platforms?
Date: 11 Apr 2000 02:36:48 GMT
In article <[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>So far I have implemented the RC4, that together with the startup code
>for the cpu is 860 bytes... Not super but not too large either. The
>next biggest thing will be the hash.
That is WAY larger than I'd hope for. The key initialization and the
stream output should be able to share code. I'd aim for < 100 bytes,
even in C.
>I designed the rc4 code not to reserve 256 bytes of ram, but to have a
>pointer supplied at run time...
That's reasonable.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Encode Book?
Date: Tue, 11 Apr 2000 02:37:41 GMT
lordcow77 wrote:
>
> In article <[EMAIL PROTECTED]>, Tom St Denis
> <[EMAIL PROTECTED]> wrote:
> >Pretty much ya, plus you never see anything *new* from her. If
> she
> >wants to get known [or have her side of the story] she should
> have a
> >webpage or talk in sci.crypt.
> >
>
> She's not milking her fame at all; I believe this topic was
> discussed viz a viz "Sophie Germain primes." The sad truth is
> that the mathematics profession has a paucity of females at the
> highest levels of it. When someone her age discovers such an
> interesting algorithm, but especially a female, it is only
> natural that the media would choose to jump over it. Besides,
> strictly speaking there's nothing wrong with choosing to write a
> book about her involvement in the whole situation; it's done all
> the time in other areas. Tom, what precisely do you expect her
> to invent or to prove next? A proof of the Extended Riemann
> Hypothesis? A proof of the ABC conjecture? A proof that P!=NP? A
> proof that RSAP is polytime equivalent to factoring? Suggesting
> that not posting on sci.crypt implies some lack of character or
> ability is certinaly presumptous. Sci.crypt has about ten
> reasonably competent regular posters, with Douglas Gwyn, Jim
> Gilogy, and Bob Silverman being about the most prominent.
I can sum up my gut reaction for you with "bite me". I can see being
busy and not posting often such as some "specialists". But I have yet
to hear anything from her, or see anything she has done. The "paper" I
saw of hers was second hand thru some media thingy...
I couldn't give a rats azz if she were female, male, or a martian, the
fact she does not maintain *any* public discussion or etc, shows me that
she is not really in the field, or just shy...
Tom
------------------------------
From: "Kim J.-H." <[EMAIL PROTECTED]>
Subject: Looking for crypto short course or workshop
Date: Tue, 11 Apr 2000 11:40:58 +0900
I would like to want to know about crypto short course or workshop to be
held.
The topic may be general or specific.
I am waiting for your guidance.
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Encode Book?
Date: 11 Apr 2000 02:41:27 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>I can sum up my gut reaction for you with "bite me". I can see being
>busy and not posting often such as some "specialists". But I have yet
>to hear anything from her, or see anything she has done. The "paper" I
>saw of hers was second hand thru some media thingy...
>
>I couldn't give a rats azz if she were female, male, or a martian, the
>fact she does not maintain *any* public discussion or etc, shows me that
>she is not really in the field, or just shy...
Come to think of it I haven't seen anything here on the ng lately
by Shamir, Knudsen, Simmons, etc. etc. either. You just aren't looking
in the right places.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Crypto for embeded platforms?
Date: Tue, 11 Apr 2000 02:45:04 GMT
Paul Rubin wrote:
>
> In article <[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> >So far I have implemented the RC4, that together with the startup code
> >for the cpu is 860 bytes... Not super but not too large either. The
> >next biggest thing will be the hash.
>
> That is WAY larger than I'd hope for. The key initialization and the
> stream output should be able to share code. I'd aim for < 100 bytes,
> even in C.
No way, alot of the indexing code is not easy for a C compiler, the
startup code is not mine it's part of the C library. I can show you the
source I have, maybe you can optimize it? hehe
> >I designed the rc4 code not to reserve 256 bytes of ram, but to have a
> >pointer supplied at run time...
>
> That's reasonable.
I thought it was a good idea.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: yet another perm poly idea
Date: Tue, 11 Apr 2000 02:47:57 GMT
Is it possible given a permutation polynomial modulo 2^w [w>1] to calc
the inverse polynomial? My main idea is to create an order [of say] 5
or so polynomial with random coefficients [fixed to make a p.p]. So if
you had a order-5 polynomial and say a 64 bit input the keysize would be
64 + 5*63, since all the coefficients [that go with an x] have to be
odd, and the first one can be anything. So you get
P(x) = K1 + K2x + K3x^2 + K4x^3 + K5x^4 + K6x^5 (mod 2^w)
So given K1..K6 I need to find P^-1(x) ...
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: yet another perm poly idea
Date: Tue, 11 Apr 2000 02:49:47 GMT
Arrg, I just missed how amazingly stupid on an idea this is. The fact
that the msb of the input doesn't effect the lower bits at all
completely escapted me.
Sorry guys,
Tom
Tom St Denis wrote:
>
> Is it possible given a permutation polynomial modulo 2^w [w>1] to calc
> the inverse polynomial? My main idea is to create an order [of say] 5
> or so polynomial with random coefficients [fixed to make a p.p]. So if
> you had a order-5 polynomial and say a 64 bit input the keysize would be
> 64 + 5*63, since all the coefficients [that go with an x] have to be
> odd, and the first one can be anything. So you get
>
> P(x) = K1 + K2x + K3x^2 + K4x^3 + K5x^4 + K6x^5 (mod 2^w)
>
> So given K1..K6 I need to find P^-1(x) ...
>
> Tom
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Crypto for embeded platforms?
Date: 11 Apr 2000 02:56:07 GMT
In article <[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>> That is WAY larger than I'd hope for. The key initialization and the
>> stream output should be able to share code. I'd aim for < 100 bytes,
>> even in C.
>
>No way, alot of the indexing code is not easy for a C compiler, the
>startup code is not mine it's part of the C library. I can show you the
>source I have, maybe you can optimize it? hehe
A lot of times you have to try different variants til you get the best
code out of your compiler. Sometimes a[i] doesn't work as well as *(a+i), etc.
Maybe it's best to just write a small reference implementation in C
and don't worry about careful optimization. That should be done in asm anyway.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,alt.politics.org.nsa,talk.politics.crypto
Subject: Re: new Echelon article
Date: Tue, 11 Apr 2000 03:02:48 GMT
In article <8b9fif$kvn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <
> tMVB4.198$[EMAIL PROTECTED]
> m>,
> "Leo Sgouros" <[EMAIL PROTECTED]>
> wrote:
> >
>
> > Last night at a function in DC Director Tenet made the comment that
only in
> > America could the leader of the intelligence community come and
speak and
> > mingle with the citizens-he was being given an award by AHEPA and
it made me
> > think along similar lines-but this being America, founded on
business and
> > capitalism, I would think it would be entirely natural for the
spooks to
> > help out business.Wrong, yes.But I think in the evolution of a
world economy
> > it is a foregone conclusion.And it doesnt necessarily mean planting
bugs in
> > a hotel room-the intel guys sometimes have excellent foresight and
can spot
> > trends, and they obviously know about the new tech and its
applications.I
> > guess the question should be how can this become a fairer process
where all
> > businessmen could get some sort of nod or helping hand-maybe a
lottery or
> > some other method whereby your company gets to get juicy details
this week,
> > someone elses next(this would also mean a transparent intelligence
> > community-another good thing BTW).It would end up being another way
to
> > perpetuate a spy vs spy mentality,and to tell you the truth if it
was for
> > purposes other than murder and drugs and terror, I say lets give
the spooks
> > something safe to do.Lord knows they screw up the dangerous stuff.
> >
> What screw-ups are you referring to? Who
> would you rather have gathering intel on the
> "dangerous" stuff? Of course, for security
> reasons, we are unaware of many successful
> achievements by the U.S. intel community.
> Consider, for example, that there are no
> significant attacks against the continental
> U.S. by foreign terrorists.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> Mr Tenet has done a wonderful job protecting the interest's and
security of the United States of America! Every American should be
respectful to his accomplishments. Sincerely, TCMCOMSPECUSA1
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Factoring Large Numbers - I think I figured it out!
Date: Tue, 11 Apr 2000 03:06:22 GMT
In article <8b9q9a$gv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <8b8ilq$oh0$[EMAIL PROTECTED]>,
> Bob Silverman <[EMAIL PROTECTED]> wrote:
> > In article <MuOB4.5485$[EMAIL PROTECTED]>,
> > "Richard Anthony Hein" <[EMAIL PROTECTED]> wrote:
> > > It's not an algorithm Bob. It's a methodology. It would eventually
> > become
> > > a microchip specific to the task. Right now, it's like a vacuum
tube
> > (no,
> > > it doesn't look like a vacuum tube - it's at that level of tech
> >
> > You really don't know what you are talking about. If it is a
> > "method" implementable on a microchip then it is equivalent to some
> > finite state machine and hence HAS A DESCRIPTION AS AN ALGORITHM.
> >
>
> Hey Richard- you should listen to Bob
> Silverman because everything he has written
> is correct. Scientists are trying
> to develop a new physical apparatus that will
> give us great new factoring power. It's called
> a quantum computer (QC) and it *might* even
> be able to do new proofs or calculations that
> would take too long for us or our classical
> finite state machines (FSMs) to verify. If you
> can build a reliable QC then we can run Shor's
> algorithm on it to factor large numbers
> efficiently.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> "Sieving" will be around for quite some time, Sincerely,
TCMCOMSPECUSA1
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Tue, 11 Apr 2000 03:07:44 GMT
Mok-Kong Shen wrote:
> Bryan Olson wrote:
> >
>
> > > According to the above, the answer should be yes. Now consider
> > > applying compression to both, then they are likely to get
compressed
> > > to different lengths.
> >
> > No. The identity function is an optimal compressor for the
> > given language (all n-bit strings equally likely). In fact,
> > if shorter strings are more likely than longer strings, then
> > any compression function for which some string has a shorter
> > image must have a worse expected compression ratio than the
> > identity function.
> >
> > Arbitrary compression functions will produce differing
> > relative image lengths. For any finite string there's some
> > compressor that compresses it to one bit.
> >
> > > Would that fact conform to their having
> > > the same entropy?
> >
> > The actual situation is consistent.
> >
> > My previous posts answers the question of why a conventional
> > compression algorithm, which is not optimal for the given
> > language, does so much better on the sample string.
>
> Which one is your 'previous post'?
Most recent by me, same strand of the thread
(well, now it's next most recent).
> I did't see any previous post
> of yours that mentioned the word 'compression'.
Correct; it doesn't. Generalize.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto
Subject: Re: 2048 Bit Encryption?
Date: Tue, 11 Apr 2000 03:10:44 GMT
In article <8bevi9$nak$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Anthony Stephen Szopa wrote:
> > >
> > > > "the algorithm used in key generation will select randomly from
> > > > that space" The algorithm does not select the random numbers.
> > > > Every process requires random user input. This input is the key.
> > > > The user picks the order of the processes. The user enters
usually
> > > > 10 or 14 different numbers for each process. The user inputs how
> > > > many times each process is run with different input. Etc.
> > >
> > > This is a perfect example of why people dismiss your software.
The first
> > sentence betrays either a complete ignorance of the issues, or a
purposeful
> > attempt to confuse the truth. Pure algorithms do not operate
randomly, they
> > operate deterministically. So the algorithm _cannot_
select "randomly from
> > the space".
> > >
>
> A side note- In *principle* classical
> computation does not have to be
> deterministic. Suppose a turing machine could
> be enabled to toss an unbiased coin and to
> choose its steps randomly. Then it would
> follow some *single* randomly chosen path
> and the probability of an output X would be the
> sum of the probabilities of all computations
> leading to X.
> [ I don't know anything about OAP-L3 but I'm
> dubious towards it due to the seemingly valid
> criticisms that are being posted. ]
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
> Is this site great or what? I love it! TCMCOMSPECUSA1
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: DNA steganography
Date: Mon, 10 Apr 2000 20:33:36 -0700
[EMAIL PROTECTED] wrote:
>I wonder how much or how often technology
> has appeared in sci-fi before appearing in reality. (In one of the "Star
> Trek TNG" episodes, the android Data used a [bogus] fractal-based
> cryptosystem.)
There's an episode of TNG involving a Klingon spy transcribing/encoding
sensitive Federation information from an "iso-linear chip(?)" into
proteins - amino acid sequences - and injecting said proteins into his
bloodstream in an effort to smuggle the information off the Enterprise.
This is also a form of biochemical steganography. If we
(hypothetically) encoded info as DNA sequences, attached a promoter to
the front of the sequence and then introduce it into a cell (bacteria)
or a solution with ribosomes, we could get the sequence transcribed into
a protein and introduce it into someone's blood serum for later
"retrieval."
But what about the immune response of the carrier? Info coded as
proteins will prompt an immune response from the carrier since those
sequences will not match any normally occurring serum proteins in the
blood stream. Antibodies to the proteins should appear in at (most?) a
week(?), limiting the useful carry time for the info. The protein
concentration in the blood serum would have a half-life on the order of
days as the body eliminates it with macrophages after tagging the
proteins with antibodies.
And what a novel example of information "leakage" to the cryptanalyst.
Someone suspected of protein-message smuggling? Take a serum sample and
look for active antibodies (call them A) to the message M. Inject
portions of the serum into another animal to make antibodies to the
antibodies ( call them B). The region of the anti-antibody (B) that
binds to the antibody (A) which bound to some portion of M is the same
shape as that portion of M - so would it then be the same amino acid
sequence as that portion of M? There's a chance it is. Or maybe it's
close (per some rules of protein shape prediction from amino acid
sequence.) Even if it isn't exact, the cryptanalyst knows the original
amino acid sequence in M must generate the same shape s/he found in
anti-antibody (B). Some slight variation from the amino acid sequence in
the anti-antibody (B) may be the one sought.
However, predicting protein shape from amino acid sequences is still
more art than science, but we're getting better at it every day.
Maybe our own immune systems will prevent us from ever making
protein-transcibed DNA steganography a workable message carrying system.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: Checksum for digits
Date: Tue, 11 Apr 2000 13:43:55 +1000
Having 2 different people key in the numbers may be the best bet if there is
no identifiable or verifable property of this number.
That way, any keying error is likely to be different between the operators -
and can then be manually checked.
A keying agreement between the operators is likely to be accurate entry of
the number.
Of course, i suspect this won't suit the goal behind the question - but it
did work for re-keying telephone directories when telcos wouldn't provide
electronic versions.
lyal
Bill Unruh wrote in message <8cttkh$6bv$[EMAIL PROTECTED]>...
>In <8csfud$ml2$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>
>>I'm writing an application where the user needs to enter a number of
>>digits (>30) in a field and I need a good algorithm that can verify
>>that the data the user has entered is correct. It should support
>>variable checksum length and should detect as many faulty digits as
>>possible. It's not necessary to detect which digits are incorrect.
>
>How do you know the digits they entered are correct? Is there only one
>30 digit number they can enter, or are there a whole bunch? What is
>there about that whole bunch that makes them special. Obviouly if any
>number is a possible valid input then there is no way of using the
>number to decide if it is wrong.
------------------------------
** 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
******************************
