Cryptography-Digest Digest #792, Volume #9 Mon, 28 Jun 99 14:13:03 EDT
Contents:
Block Ciphers and Crpytanalysis (JPeschel)
Re: The One-Time Pad Paradox (John Savard)
Re: The One-Time Pad Paradox (John Savard)
Re: The One-Time Pad Paradox (John Savard)
Re: The One-Time Pad Paradox (John Savard)
Re: VIC cipher now described on web site (John Savard)
crypt basics ("Bernd Wachmann")
Re: Moore's Trend (John Savard)
Re: xtea ([EMAIL PROTECTED])
Re: one time pad ([EMAIL PROTECTED])
Re: Interesting RSA question (Gilad Maayan)
Re: one time pad ([EMAIL PROTECTED])
Re: one time pad ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox ([EMAIL PROTECTED])
Re: The One-Time Pad Paradox ([EMAIL PROTECTED])
Re: Critique of Street Performer Protocol paper (Anonymous)
Re: one time pad (Mickey McInnis)
Re: one time pad (John Briggs)
Re: Interesting RSA question (David A Molnar)
Re: one time pad (Mickey McInnis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Block Ciphers and Crpytanalysis
Date: 28 Jun 1999 15:30:51 GMT
I've recently added my friend Fauzan Mirza's report, "Block Ciphers and
Crpytanalysis" to my web page.
"This report gives a basic introduction to block cipher design and analysis.
The concepts and design principles of block ciphers are explained,
particularly the class of block ciphers known as Feistel ciphers. Some
modern block cipher cryptanalysis methods are demonstrated by applying
them to variants of a weak Feistel cipher called Simplified TEA (STEA),
which is based on the TinyEncryption Algorithm(TEA). "
You'll find it in the "Algorithms and Attacks" page.
Fauzan has given me permission to host the report of my site rather
than link to it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The One-Time Pad Paradox
Date: Mon, 28 Jun 1999 15:34:02 GMT
[EMAIL PROTECTED] (Charles Blair) wrote, in part:
> I don't know thermodynamics, but isn't it like the possibility
>that all the gas molecules will migrate to one half of a room,
>suffocating the occupants of the other half?
Yes, it is similar. I only continue to speak of this very remote case
because it is theoretically fascinating.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The One-Time Pad Paradox
Date: Mon, 28 Jun 1999 15:34:49 GMT
[EMAIL PROTECTED] (Coen Visser) wrote, in part:
>This way of thinking leads to an ever increasing amount of kludges to the
>one-time-pad.
Yes, and *that* is where both madness and insecurity lies.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The One-Time Pad Paradox
Date: Mon, 28 Jun 1999 15:37:45 GMT
"Robert C. Paulsen, Jr." <[EMAIL PROTECTED]> wrote, in part:
>Marks devised a way
>to pass (verbally, I believe) security checks to agents through a third
>party in a way that the third party would not be able to reveal the
>security check to anyone else. In a footnote he said he was told not to
>reveal the technique even now, 50 years later!
Actually, I'm not too surprised: that sounds like a technique which
may still be useful.
During World War II, the OSS devised a handgun with such a good
silencer that almost no sound - and no flash of light - came from the
gun when it was fired. That, too, is _still_ too dangerous to have
floating around...
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The One-Time Pad Paradox
Date: Mon, 28 Jun 1999 15:41:20 GMT
[EMAIL PROTECTED] wrote, in part:
>The OTP is just like saying, I will give the message in secret and
>share the key over the medium. If you have a secure medium, what's the
>point? Well you can send messages at later dates,
Precisely. You can share the key well in advance, over a different
slow medium, such as face-to-face contact.
While I believe you used the term "key agility" in an incorrect
technical sense, your remaining points are quite correct. When you run
out of key, you are stuck - and with computers able to implement
fantastically complex conventional ciphers, why bother with the OTP?
It is, however, an interesting theoretical case.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: VIC cipher now described on web site
Date: Mon, 28 Jun 1999 15:43:49 GMT
[EMAIL PROTECTED] (UBCHI2) wrote, in part:
>That cipher must have been a Soviet red herring. There is no way to implement
>a hand cipher of that complexity.
Although I disagree - a spy otherwise unsuspected, living as an
ordinary individual, can, one quiet evening in a month, encode or
decode a single message in such a cipher - it certainly _is_ correct
that this hand cipher is far too complex for use, say, as a _field_
cipher for soldiers.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: "Bernd Wachmann" <[EMAIL PROTECTED]>
Subject: crypt basics
Date: 28 Jun 1999 15:46:52 GMT
Dear all,
I'm new in the field of cryptography and I would like to
ask some of you, which books would be good to
learn the basics and which journals and internet
homepages could help to get information about
state of the art cryptography.
Thanks in advance,
Bernd Wachmann
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Moore's Trend
Date: Mon, 28 Jun 1999 15:49:24 GMT
[EMAIL PROTECTED] (Christopher) wrote, in part:
>I know it's counter to the way things are done around here, but wouldn't
>secret algorithms be the choice then. Presuming of course both ends of
>the link are secure so the code _cannot_ be examined.
Secret algorithms *are* a good way to counter this threat, since they
make the problem of breaking the cipher open-ended. Of course, those
who consider that strategy unsound have a valid point too: most people
seeking to transmit something in cipher would not be able to construct
a good enough algorithm. And for a bank to distribute a "secret"
algorithm on CD-ROMs to its customers wouldn't work: the problem of
dissasembling code is so much simpler than cryptanalysis it isn't
funny.
Using a stream/block cipher with an internal state considerably larger
than the block size may be a useful strategy.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: xtea
Date: Mon, 28 Jun 1999 15:05:22 GMT
In article <[EMAIL PROTECTED]>,
Peter Gunn <[EMAIL PROTECTED]> wrote:
> > y += ((z << 4) ^ (z >> 5)) + (z ^ sum) + K[sum & 3];
> > sum += DELTA;
> > z += ((y << 4) ^ (y >> 5)) + (y ^ sum) + K[(sum >> 11) & 3];
> you've added brackets to show how you think the expressions
> should be evaluated, but since this looks to be different from the
> operator precedence of ANSI C, how did you decide that was
> what Wheeler & Needham intended?
Well any ANSI C compiler will do the following
1) shift Z left 4
2) shift Z right 5
3) xor together #1 and #2
4) xor Z and sum
5) add #4 to #3
6) add K[...] to #5
If you think about it, the shifting must happend like that. The shifts
are fixed which is why I put brackets around it. A compiler might view
it as
z << (4 ^ z << 5) which would be way off. The brackets also make it
clearer.
The authors wanted to mix XOR and ADD so I know that the inner brackets
xor and the outter add. So you could write it as
((((z << 4) ^ (z >> 5)) + z) ^ sum) + K[sum & 3]
To keep the mixing (xor/add) however I think it's easier to read the
way I wrote it. Also this is how the code was written in the paper
(minus the brackets).
The pseudo-code in the TEA papers is crap. I would have suggested that
they presented pseudo-code and not C code. It's easier to read some
sort of standard notation then C code.
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
Date: Mon, 28 Jun 1999 01:05:42 -0400
From: [EMAIL PROTECTED]
Subject: Re: one time pad
Terry Ritter wrote:
>
> On Sun, 27 Jun 1999 11:04:31 -0600, in
> <[EMAIL PROTECTED]>, in sci.crypt
> [EMAIL PROTECTED] (Jerry Coffin) wrote:
>
> >[...]
> >Right now, we don't know any way of predicting when a radioactive atom
> >will decay -- as far as we know, it's entirely random. On a
> >reasonable-sized statistical sample, we can predict with reasonable
> >accuracy how many will decay in a particular length of time, but still
> >have no idea about predicting when an individual one will decay.
> >
> >I believe Terry Ritter's point was that even though the problem
> >appears intractable right now (and has for some time) there's no way
> >to prove that nobody will ever be able to do so more accurately than
> >we can now.
>
> No, I had not considered new insights into radioactive decay, but I
> suppose that would qualify as a possible weakness. More likely would
> be unnoticed problems in the detector, or other problems in the
> overall design. Maybe we can get some form of predictability in terms
> of non-flat distribution in particular situations. Maybe the physical
> distribution of the radioactive material and its distance from the
> detector is more important than that now seems. Maybe the hardware
> will age in a useful way. Maybe the generator becomes nonrandom after
> a power outage, or during a brownout, or when the AC fans are on. A
> whole design in involved, and there is just a lot more there -- and a
> lot more to go wrong -- than a radioactive handwave would indicate.
>
> >[...]
> >My observation has been that while Terry has a good basic point, it's
> >NOT particularly relevant to a lot of practical use: if you look
> >around at products that use encryption, and ways they've been broken,
> >it quickly becomes apparent that breaking the fundamental algorithms
> >is just about the last thing to worry about.
>
> Yes, but practical strength never was my point. My point is the
> unjustified belief in OTP over every other cipher because of the
> theoretical proof.
>
> I dispute that the theoretical OTP proof implies a proof for a
> practical OTP. I assert that there is no proof for a practical OTP
> unless the pad can be proven or guaranteed "random" or "unpredictable"
> in practice.
Given the separation of cipher strength from gey generator strength
previously mentioned, the criticism above applies to all cipher
systems. Not only all ciphers now in existence, but all possible
ciphers that might be invented.
So, given that it is and will remain impossible to prove a negative,
that there are no weaknesses in a key generator, we can conclude that
there cannot be perfect cipher systems. LIke Godels proof of the
incompleteness of mathematical logics, we can now take this lack of
provability for granted.
This does _not_ mean we cannot judge or eventually measure the strength
of ciphers, key generators, or encryption systems. And saying that an
OTP is provably secure can be accurately interpreted to mean that no
sudden collapse _of the cipher_ is possible in the way that PKC is
theoretically vulnerable to advances in applied math.
------------------------------
From: [EMAIL PROTECTED] (Gilad Maayan)
Subject: Re: Interesting RSA question
Date: Mon, 28 Jun 1999 16:56:47 GMT
Thanks for your reply.
About that padding - if it's completely random, you wouldn't be able
to read the decrypted message, would you? I assume you'd have to have
some sort of padding technique that would allow you to descramble the
original message from the padding and read it, once decryption has
taken place. Correct me if I'm wrong.
------------------------------
Date: Mon, 28 Jun 1999 01:09:24 -0400
From: [EMAIL PROTECTED]
Subject: Re: one time pad
I'm local so I'll see if I can find the RTFM administrator.
David A Molnar wrote:
>
> [EMAIL PROTECTED] wrote:
> [Question about updating crypt cabal FAQ]
>
> > I plead complete ignorance, but am interested in an update. What work
> > needs to be done?
>
> Logistically - I remember someone mentioning that the FAQ is
> posted via an autoposting service hosted at rtfm.mit . This
> is password-protected. Some way must be found around that. :-)
>
> Content -- The list of references probably needs updating.
> The discussion of one-time pads could be
> enlarged, especially since it keeps coming up.
>
> Personally, I would like to see sections on
> provable prime generation, "strong primes",
> low-exponent attacks on RSA, the new
> P1363 standard, AES, and probably more.
> i
> It's been a while since I've closely read the FAQ, so
> I'll go do that now.
>
> I'm asking about current efforts because I don't want
> to duplicate efforts or step on anyone's toes. Also,
> there's the RSADSI FAQ out there now, and if that is
> considered current and comprehensive enough
> then perhaps it's best to point ppl to it.
>
> Thanks,
> -David Molnar
------------------------------
Date: Mon, 28 Jun 1999 01:11:05 -0400
From: [EMAIL PROTECTED]
Subject: Re: one time pad
I'd suggest "Getting Started" and "How To" sections. We seem to get a
lot of traffic on those topics.
David A Molnar wrote:
>
> David A Molnar <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > [Question about updating crypt cabal FAQ]
>
> >> I plead complete ignorance, but am interested in an update. What work
> >> needs to be done?
>
> > Logistically - I remember someone mentioning that the FAQ is
> > posted via an autoposting service hosted at rtfm.mit . This
> > is password-protected. Some way must be found around that. :-)
>
> Oh - the FAQ mentions that the editors may be reached by
> [EMAIL PROTECTED] . Hopefully this is still active.
>
> Another thing which could be added : the section on hash
> functions makes no mention of SHA.
>
> -David
------------------------------
Date: Mon, 28 Jun 1999 01:15:03 -0400
From: [EMAIL PROTECTED]
Subject: Re: The One-Time Pad Paradox
[EMAIL PROTECTED] wrote:
>
> The One-Time Pad is the one theoretically perfect cipher. Provided it is
> applied in strict accordance with the theoretical conditions.
>
> One must use a key that is truly and genuinely random.
>
> Now, there is a small, but finite, probability that the random key will
> happen to be 000000...
>
> If one uses such a key, one is sending one's message in plaintext.
>
> If one refuses to use such a key, one is causing one's key to be
> nonrandom, hence one is spoiling the perfection of the one-time-pad.
>
> This qualifies as a genuine paradox, and as such may well be fruitful,
> just as paradoxes in mathematics and physics have occasionally led to new
> paradigms.
>
> One way to resolve the "next step" after this paradox: let us suppose
> one's key *does* look random, but applying the key to the message creates
> what _appears_ to be the plaintext of a message saying (in different
> words) essentially the same thing as the message you want to keep
> secret...
>
> is the following: before applying the OTP, encrypt one's message with a
> probabilistic encryption method. If this happens, repeat the probabilistic
> encryption, and use the same OTP again, _then_ send the result.
>
> Since the pad is random, the only "information" is that the _ciphertext_
> is random-looking, and one already has the full ciphertext.
>
> However, that *does* introduce a subliminal channel...
>
> (I call this Comfort-Zone Encryption.)
>
> The desired situation to avoid this paradox is this: you have N plaintext
> messages, you have N keys, and you have N ciphertext messages. But no one
> of the N keys is "zero", and *none* of the N ciphertext messages could be
> mistaken (by someone who doesn't realize a one-time-pad is being used) for
> any plaintext - or could be thought to be more closely associated with one
> plaintext message than another.
>
> Stating the condition helps to see what is necessary. A step (but an
> incomplete one) would be to take an alphabetic text, and by means of a
> random key encipher it to a ciphertext consisting of 26 funny-looking
> symbols instead of the 26 letters, which occasionally can have meaning
> associated with them.
>
> Surely there is, in mathematics, some class of equi-spaced binary strings
> applicable to this kind of thing...
>
> John Savard
------------------------------
Date: Mon, 28 Jun 1999 01:25:36 -0400
From: [EMAIL PROTECTED]
Subject: Re: The One-Time Pad Paradox
[EMAIL PROTECTED] wrote:
>
> The One-Time Pad is the one theoretically perfect cipher. Provided it is
> applied in strict accordance with the theoretical conditions.
>
> One must use a key that is truly and genuinely random.
>
> Now, there is a small, but finite, probability that the random key will
> happen to be 000000...
>
> If one uses such a key, one is sending one's message in plaintext.
>
> If one refuses to use such a key, one is causing one's key to be
> nonrandom, hence one is spoiling the perfection of the one-time-pad.
>
> This qualifies as a genuine paradox, and as such may well be fruitful,
> just as paradoxes in mathematics and physics have occasionally led to new
> paradigms.
>
> One way to resolve the "next step" after this paradox: let us suppose
> one's key *does* look random, but applying the key to the message creates
> what _appears_ to be the plaintext of a message saying (in different
> words) essentially the same thing as the message you want to keep
> secret...
>
> is the following: before applying the OTP, encrypt one's message with a
> probabilistic encryption method. If this happens, repeat the probabilistic
> encryption, and use the same OTP again, _then_ send the result.
>
> Since the pad is random, the only "information" is that the _ciphertext_
> is random-looking, and one already has the full ciphertext.
>
> However, that *does* introduce a subliminal channel...
>
> (I call this Comfort-Zone Encryption.)
>
> The desired situation to avoid this paradox is this: you have N plaintext
> messages, you have N keys, and you have N ciphertext messages. But no one
> of the N keys is "zero", and *none* of the N ciphertext messages could be
> mistaken (by someone who doesn't realize a one-time-pad is being used) for
> any plaintext - or could be thought to be more closely associated with one
> plaintext message than another.
>
> Stating the condition helps to see what is necessary. A step (but an
> incomplete one) would be to take an alphabetic text, and by means of a
> random key encipher it to a ciphertext consisting of 26 funny-looking
> symbols instead of the 26 letters, which occasionally can have meaning
> associated with them.
>
> Surely there is, in mathematics, some class of equi-spaced binary strings
> applicable to this kind of thing...
It may be easier to make your message look like something else instead
of making it look like nothing (noise). Consider grabbing an image or
salacious diary snippet as your decoy, and letting it "shine through"
your encryption. Given you and I have a pad consisting of noise, I send
you a message by selecting a decoy, creating the decoy-plaintext delta
by XOR or any suitable operation, and encrypting the delta with the
actual shared pad. When I send the decoy and encrypted delta the decoy
will be visible.
To recover the plaintext you apply the pad to the delta and the
recovered delta to the decoy. At a cost of 2x message size you have
complete control over the material that "shines through" your envelope.
Essentially this is a variant on selecting a key from among published
works and keeping it secret. In this instance I enclose a copy of the
published work, which removes the requirement that it be pre-known to
the recipient, in order to distract a eavesdropper with a decorated
envelope.
I suspect there would still need to be _some_ agreement on decoy
material because you might be offended by my taste is envelope
decorations. Maybe springer-verlag is a better choice than salacious
diary tidbits.
------------------------------
Date: Mon, 28 Jun 1999 19:27:42 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Re: Critique of Street Performer Protocol paper
[EMAIL PROTECTED] writes:
> Anonymous <[EMAIL PROTECTED]> wrote:
> > However, another recent product introduction is more consistent with my
> > suggestions, a low-cost device for special purpose Internet browsing,
> > with a non-Windows OS that might offer higher hopes for security. This
> > is the iToaster, announced yesterday by Microworkz.com. It is said to
> > use a "hybrid" OS, based on Linux and BeOS.
> >
> > While this may not be the perfect machine for viewing secured data, it
> > is an example of a non-Windows machine with a custom OS, used for
> > specialized purposes. This is exactly the niche into which a high
> > security machine for viewing copyrighted data might fall.
>
> It appears to have no significant relevance to the arguments
> surrounding the Street Performer Protocol.
The relevance is with regard to the following comment from the original
paper:
: Furthermore, very few personal computers or homes are defended
: well enough to justify having information inside which, if posted
: anonymously to the Internet, will cost their owner even a few thousand
: dollars, let alone millions of dollars. (For comparison, the reader
: may consider whether he would be willing to keep a briefcase with even
: $10,000 belonging to his boss in his house, with no additional security
: or insurance.)
This was part of the argument that protecting copyright through
watermarking and restrictions on redistribution would not be practical
because of the risk of theft and associated liability. Clearly it will
be necessary to have a highly secure system in order to protect users
against this. And equally clearly, providing such a level of security
while maintaining compatibility with the installed base of Windows
machines will be virtually impossible.
The question therefore becomes whether there is a market niche for a high
security, non-Windows machine which is used specifically for the purpose
of viewing copyrighted material. The iToaster is not intended for this
specific purpose, but it is an example of a non-Windows niche machine,
and if it succeeds then other niches may succeed as well.
A better candidate for a high-security OS is EROS, the Extremely Reliable
Operating System. Based on the "capabilities" concept, it provides a
certain amount of provable security and could be an excellent foundation
for this application. It's freely available now under a Mozilla-like
license, although you're not going to run Quake on it right away.
See http://www.eros-os.org/.
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: one time pad
Date: 28 Jun 1999 16:59:46 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) writes:
|> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
|>
|> >So what clue does the cryptanalyst have that
|> >*this* good plaintext is any more correct than it was those zillions
|> >of other times (in his Methuselah-like lifetime) when he obtained
|> >good plaintexts that turned out to be incorrect decryptions?
|>
|> But in real life, our RBG might generate all zeroes because of a short
|> circuit, and sending out plaintext every time that happened is not a
|> good idea. There is a problem here, but eliminating a tiny fraction of
|> "obviously bad" sequences will normally only eliminate a number of
|> nonsense plaintexts that wouldn't be accepted anyways.
|>
...
|>
|> John Savard ( teneerf<- )
|> http://members.xoom.com/quadibloc/crypto.htm
Well, if you're going to monitor your "random" bitstream and check it,
you shouldn't "silently" throw away bad sequences. If something's
happened to your RNG to make it put out non-random bits for a while,
you need to determine the problem and fix it instead of continuing
to use your intermittently broken RNG.
------------------------------
From: [EMAIL PROTECTED] (John Briggs)
Subject: Re: one time pad
Date: 28 Jun 99 13:18:02 -0400
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) writes:
> Ah, yes. While that extreme case is extremely improbable, surely you
> must admit that there is a chance that the Adversary, by mistake,
> might simply assume one was sending plaintext (on account of having
> run out of one-time pads)?
>
> I know the _theory_, but I think there's a point being missed.
Certainly. The point is that the OTP is an optimal defense if you're
guarding against an optimal attacker. It minimizes the probability
(averaged over all possible key choices) that the best possible attacker
(optimized for your particular cryptosystem) will guess right. No other
method gives a lower probability for the best possible attacker (against
that method) to guess correctly. Every other attacker will, of course,
do at least as poorly as the best attacker on average.
Other defenses _can_ do better if we restrict our attention to certain
classes of attackers, e.g. attackers who are likely to guess that
plaintext == ciphertext.
There is an analogy to rock/paper/scissors. A completely random friendly
strategy is optimal in the sense that every other friendly strategy is
weaker against at least one opposing strategy. Non-random or non-uniform
friendly strategies can be stronger than this if (and only if) we
restrict our attention to a subset of all possible opposing strategies.
If our random number comes up "rock" 100 times in a row and the opponent
has been slapping us with "paper" 100 times in a row, there is a temptation
to override the RNG to "scissors" when it comes up "rock" for the 101st
time. Such an override is sub-optimal in the sense that there exists an
opponent that can exploit it. Such an override can be smart if (and
only if) we restrict our attention to a particular class of opponents.
If there is a point that is missed, perhaps it is that real world
opponents are sub-optimal. They tend to look for simple patterns.
They don't always know everything about your system. If you play to
such an opponent you can do better than OTP against him.
The counter-point is that in the process you open yourself (at
least theoretically) to attack by an opponent who knows or guesses that
you are doing this and wind up doing worse than OTP against her.
John Briggs [EMAIL PROTECTED]
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Interesting RSA question
Date: 28 Jun 1999 17:50:24 GMT
Gilad Maayan <[EMAIL PROTECTED]> wrote:
> About that padding - if it's completely random, you wouldn't be able
> to read the decrypted message, would you? I assume you'd have to have
> some sort of padding technique that would allow you to descramble the
> original message from the padding and read it, once decryption has
> taken place. Correct me if I'm wrong.
Many methods of padding don't have this particular problem,
because they work like this :
message * pad = plaintext
where * means _concatenation_, not multiplication. So if your
message is "101", padding might produce
1011110010101010110101001010101101100101... as the plaintext.
Note that the top three bits are still 101, which is your message.
In practice the padding may include some indication of the length
so as to avoid confusion. This plaintext is then encrypted.
Better methods of padding do attempt to make things more
complicated by ensuring that the entire range of plaintexts
is a possible padded representation for each message.
In this case there are methods for padding and unpadding
which, as you suggest, allow you to "descramble" the message
after decrypting.
You'll want to read the RSA PKCS #1 document, as others have
suggested -- the current version is 2.0 and found at
http://www.rsa.com/rsalabs/pubs/PKCS/index.html
You will also want to check out "Optimal Asymmetric Encryption
-- How to Encrypt With RSA" by Mihir Bellare and Phillip
Rogaway at http://www-cse.ucsd.edu/users/mihir/papers/pke.html
for the explanation/rationale behind the padding described in
PKCS #1.
Thanks,
-David Molnar
------------------------------
From: [EMAIL PROTECTED] (Mickey McInnis)
Subject: Re: one time pad
Date: 28 Jun 1999 17:10:19 GMT
Reply-To: [EMAIL PROTECTED]
In article <7l0kld$d22$[EMAIL PROTECTED]>, AllanW <[EMAIL PROTECTED]> writes:
|> [EMAIL PROTECTED] (S.T.L.) wrote:
...
|>
|> > that is operating correctly, then ALL you need to do is
|> > take its output, send it to the recipient securely, and
|>
|> How?
|>
|> Doesn't the existance of a secure channel imply that no
|> encryption is needed?
|>
...
The classical method of using crypto involves a secure channel
that is not real-time, and a nonsecure real-time channel. e.g.
You send the key by a trusted courier or give it to the recipient
in person, then you send encrypted messages with real-time over an
insecure channel. For instance, you give a spy the code keys
in person before he goes to a foreign country and sends data back
by radio.
|>
|> --
|> [EMAIL PROTECTED] is a "Spam Magnet," never read.
|> Please reply in newsgroups only, sorry.
|>
|>
|> Sent via Deja.com http://www.deja.com/
|> Share what you know. Learn what you don't.
------------------------------
** 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
******************************
