Cryptography-Digest Digest #899, Volume #13 Wed, 14 Mar 01 19:13:01 EST
Contents:
Re: Crypto idea (David Schwartz)
Re: Noninvertible encryption (David Schwartz)
Re: PGP "flaw" (Bill Unruh)
Re: OverWrite: best wipe software? ("Tom St Denis")
Re: Instruction based encryption ("Tom St Denis")
Re: About one-time pad (Ben Cantrick)
Re: primes for Blum Blum Shub generator ("Tom St Denis")
Re: Instruction based encryption ("Tom St Denis")
Re: Digital enveloppe ("Tom St Denis")
Re: PGP "flaw" (Bill Unruh)
USB key storage ("Olivier LARRIGAUDIERE")
Re: Quantum Computing & Key Sizes ("Simon Johnson")
Analysis of PCFB mode (David Wagner)
Re: PGP "flaw" (Tony L. Svanstrom)
Re: USB key storage (Tony L. Svanstrom)
Re: Crypto idea (br)
Re: How good is the KeeLoq algorithm? ("Joseph Ashwood")
Re: Crypto idea (br)
Re: Crypto security of pseudo-random sequences ("Joseph Ashwood")
----------------------------------------------------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: Crypto idea
Date: Wed, 14 Mar 2001 14:07:04 -0800
br wrote:
>
> My idea it's like someone who don't know wich language I used.
> But once the plain text deciphered with the appropriate key every human
> being can read and understand Ay lovv u or Ilauv yu etc...
> Before attack, cryptanalisis is helpless.
If you are factoring an RSA key, what difference does it make what the
plaintext looks like? I strongly suspect that you have no idea what you
are talking about.
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Noninvertible encryption
Date: Wed, 14 Mar 2001 14:10:22 -0800
"SCOTT19U.ZIP_GUY" wrote:
> > You either trust your encryption or you don't. IMO, the uncomprsesed
> >data is _much_ more likely to contain vulnerabilities than the
> >compressed data is.
> I don't think it a question of trust or not. History has proved
> over and over again that blind trust is for fools. One should have
> a level of trust in one encryption method. But that does not mean
> one should be lax about things that weaken the method.
You know those cheap chain slide locks kids sometimes use to keep their
parents out of their room? The ones you can easily push through or open
with a thumbtack and rubber band? Would you put one on your front door?
If you felt your front door needed another lock, then you should get a
real lock. The only thing such a lock could possibly do is give you a
false sense of security.
In this case, it actually weakens things. Uncompressed data is much
more likely to contain exploitable patterns than compressed data. In
fact, compressibility is pretty much a measure of how patterned
something is.
DS
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: PGP "flaw"
Date: 14 Mar 2001 22:20:16 GMT
In <[EMAIL PROTECTED]> Brian D Jonas
<[EMAIL PROTECTED]> writes:
>I suppose everyone here already knows about the PGP "flaw" that has been
>in the PGP program for the last 4 years? It's no wonder that the inventor
>of PGP has left the company.... Media can call it a "flaw" but we all know
>it is a back door that uses the public key method...
Since it had a huge neon sign on it, saying "Door here" it is hard to
regard it as a back door.
>here is a quote from cnn.com's report on it
>"As it turns out, this flaw has actually existed since 1997, back when
>Phil Zimmermann, the original developer of PGP, added the data-recovery
>feature as he sought to commercialize the product for corporate use, Jones
>points out. As a safety measure, corporations want to have a way to
>decrypt data that their employees encrypt, Jones notes. "
>ok so what was the point of encryption again ? I forgot....
To protect communications from the enemy. Most companies do not regard
themselves as the enemy, but do at times mistrust their employees. To
have communication on company time with company equipment being hidden
from the company itself is regarded by many companies as undesireable,
with some justification. Thus, the message is encrypted not only to the
recipient but also to a company wide key, so the message can be recoved
by the company. This was not a back door (as above), and was a widely
advertised feature. There was debate as to whether or not it was a good
thing. But this is a feature which had to be conciously switched on.
Now, the fact that the company key was poorly protected in the key was
the bug. Not the fact that the company key could exists.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker
Subject: Re: OverWrite: best wipe software?
Date: Wed, 14 Mar 2001 22:20:56 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> >
> > "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Benjamin Goldberg wrote:
> > > >
> > > > You claim to have demonstrated a "procedure whereby the OverWrite
> > > >
> > > >
> > > > ><snip>
> > > >
> > > >
> > > > The difference between theory and practice is that in theory, theory
and
> > > > practice are identical, but in practice, they are not.
> > >
> > >
> > > Let me ask you then, using OverWrite and my procedure of a dedicated
> > > hard drive partition, etc., why will not the desired file be
> > > thoroughly overwritten? Give us just one objection and we will
> > > pursue it like a pack of dogs pursues the fox.
> >
> > Well I can say it's inconvenient to partition my drive to use your
tools. I
> > will lose all my data!
> >
> > Tom
>
>
> You need a better system. You need at least two hard drives and
> these should already have partitions on them. In this case, you
> would only have to repartition one of your existing partitions.
> You could save the data on this partition in one of your other
> partitions so you wouldn't lose it.
Are you telling me (us) how to make a computer? I have a 45gb hdisk I don't
need any more!!!
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Wed, 14 Mar 2001 22:22:34 GMT
"Michael Brown" <[EMAIL PROTECTED]> wrote in message
news:O%Er6.1308$[EMAIL PROTECTED]...
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:Ncpr6.26696$[EMAIL PROTECTED]...
> >
> > "Michael Brown" <[EMAIL PROTECTED]> wrote in message
> > news:EBlr6.915$[EMAIL PROTECTED]...
> <SNIP>
> > > Each 128 bit key is made up of 16 "instructions", each of length 8
bits.
> > The
> > > instructions go from the most significant bit down to the least
> > significant
> > > bit. The first 3 bits of each instruction are the instruction, x, and
> the
> > > next 5 bits are the parameter n.
> >
> > This won't work. Algorithms defined by their keys are normally weak
since
> a
> > subset of keys will define completely linear or differentially weak
> ciphers.
> Yep. Dead right. What I forgot to mention in my original post was that I
was
> doing this as an exercise to see if I'd got the hang of
linear/differential
> cryptanalysis. I failed :(
Well as long as you learned *something* you didn't fail :-). It took me
about 5 tries to master diff analysis of even my simple ciphers (and I am
still an amateur).
> > > "Mash" key according to the following method:
> > > Xor key with previous 128 bits of plaintext
> > > Repeat 11 times: Key = Key XOR (Key ROR 11)
> > > (ROR = rotate right)
> > >
> > > This key mashing is done every 128 bytes.
> >
> > Is the key mashing invertible?
> Nope :( David Finch pointed this out very well. Big screw-up here.
Hehe not desirable...
> > > <=== BEGIN NOTES ===>
> > >
> > > The 128 byte key mashing is just a number I pulled out of the air, so
> > quite
> > > possibly is not enough or too often.
> >
> > byte key? or bit key? Having the user make 128-bytes of entropy would
be
> a
> > pain.
> Badly worded statement (by me). I meant mashing the key every 128 bytes. I
> am not so sadist that I make people generate that much entopy! (However,
> assembly programming generally gives people the wrong view :)
Righto.
>
> > > The instruction table is quite possibly insecure, having both rotate
> left
> > > and rotate right.
> >
> > Note that rotate right = n-bit - rotate left
> Correct. I was running out of ideas for the table at that point.
Ahh Ic. well why not add something like "table lookup and substitute" ?
Tom
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: About one-time pad
Date: 14 Mar 2001 15:23:44 -0700
In article <98olde$b0l$[EMAIL PROTECTED]>, Haka <[EMAIL PROTECTED]> wrote:
>Hello, I don't know much about cryptology, but I came here searching for a
>practical way for two cgi scripts to send safely small messages through the
>internet (with perl).
>I read all of the your excellent FAQ and I would like to ask you about this
>simple solution to my problem i though of:
>[...]
I think it'd be simpler to encrypt your text with RC4 or another
competent stream cypher. That way you'd only have to set up keys once,
instead of having to go back and re-do the OTP keys every month. RC4
isn't quite as strong as OTP, but I have a hard time imaging the
extra security is worth it in this case.
You haven't said what application you're using these CGI scripts
for, but in my personal opinion, one time pad is way overkill for
what you're doing here. If your security needs are so demanding that
OTP is justified, you sure as hell shouldn't be shipping your data
back and fourth over HTTP as parameters to CGI scripts.
>So lets say I create a table about 16kb with random bytes. This table will
>be shared between the scripts and completely private (and permanent). The
>script would send a query like
>
>/host.cgi?p=x&text=padded_encoded_message
>
>where x the index in the table where the other script would start xor'ing
>the encoded bytes back.
It's bad enough that you're chancing re-using key bits, but this
sending of the offset is just handing snoopers a big fat flaw by which
to break your encryption? Let me explain...
If you happen to accidentally send two messages, one with p=95 and the
other with p=115, then a snooper who sees both messages can XOR the
encyphered bytes together and this will produce the bytes of your OTP
between 115-195. (a XOR K) XOR (b XOR K) = a XOR b. Try it. Then your
attacker can guess common letters or words from the message and use
those to recover and A and/or B. Then they XOR A (or B) with the
encrypted message and kaboom, they have those bits of the key.
Any re-use of key bits from an OTP - any at all - weakens the encryption,
usually fatally.
If you're really going to it this way, then you need to have both
scripts start out at offset 0 in the OTP in synch, and as they send or
receive messages, advance through the key bits in synch. This is easy
enough if you assume no lost messages. If you assume lost messages, it
gets a lot harder to stay in synch.
Even then, let's assume that the person who wants to break this
system can either partially or totally control the string that gets
encrypted. They can make your system send a bunch of messages whose
plaintext they know. Then snoop on the encrypted text, xor it with
their plaintext, and kaboom - they have the key.
>Now x would be a random number from 1 to 16kb. This way if each message is
>about 100 bytes, the chances of sending a different message with the same
>key (and thus revealing the authorization part of the message; some unique
>bytes that tell the other script that the message is valid) whould be
>1/16kb.
No, it would be (<length of message> / 16kb) * number of messages sent.
That is, as you send more and more messages the chances of an overlap
get greater and greater and your system gets easier and easier to crack.
This is not generally a characteristic of a good cryptosystem.
>This is good enough for me, since about 10 messages like this would be sent
>every day, and I could easily update the table like every month.
Depending on human intervention to make your crypto secure is probably
a bad idea. What happens if you get hit by a bus, but your company keeps
using this system, which only you understand and only you knew how to keep
secure? What happens if this system succeeds beyond your wildest dreams
and suddenly they start using it to send 300 messages a minute instead
of 300 a month?
And we haven't even gotten in to how hard it is to make really good
random numbers for generating a one time pad...
>What do you think?
I think you're still better off with a good stream cypher. It wouldn't
surprise me if there was a premade modRC4.pm at CPAN. You could have this
done in 20 minutes, and probably have better practical security, that way.
Heck, take a look at http://search.cpan.org/Catalog/Security/! They
have RC4, Blowfish, DES, Rijndael... even ROT13. ;]
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
Macho Law forbids me from admitting I'm wrong.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: primes for Blum Blum Shub generator
Date: Wed, 14 Mar 2001 22:24:13 GMT
"Dobs" <[EMAIL PROTECTED]> wrote in message news:98o5qk$9cc$[EMAIL PROTECTED]...
> Hello,
> I am trying to implement Blum Blum Shub generator. I need 2 large prime
> numbers p and q. Where should I take this numbers from,( I gess each time
> they generate one bit, they have to be changed) Is there any algorithm
to
> obtain such a large primes, which would be right for BBS generator.
> Thanx, best regards
> Michal
BBS is only (provably) secure when the primes are secret. Otherwise there
is not much of a point.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Instruction based encryption
Date: Wed, 14 Mar 2001 22:24:35 GMT
<[EMAIL PROTECTED]> wrote in message
news:6WMr6.172$[EMAIL PROTECTED]...
>
> Tom St Denis wrote in message ...
> >
>
> -snip-
>
> >> The 128 byte key mashing is just a number I pulled out of the air, so
> >quite
> >> possibly is not enough or too often.
> >
> >byte key? or bit key? Having the user make 128-bytes of entropy would
> be a
> >pain.
> >
>
>
> I agree, so do you trust PGP's session-key generation on standard PC
> hardware?
>
>
>
I don't see the connection.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Digital enveloppe
Date: Wed, 14 Mar 2001 22:25:50 GMT
"br" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> I have no confidence on PGP or any other software.
> Once, my idea of digital enveloppe achieved, I will disclose to everyone
> the source. Everyone could compile it and use it.
What does your d.e idea do anyways? Is it a public key algorithm,
symmetric? etc...
> If you feel safe using PGP, great.
I don't use PGP either...
> Digital enveloppe is secure and easy to achieve.
I'll bet.
> I'm just trying to find better formula than that I had yet realized.
> Thanks for your comment.
Righto.
Tom
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: PGP "flaw"
Date: 14 Mar 2001 22:30:06 GMT
In <[EMAIL PROTECTED]> Brian D Jonas
<[EMAIL PROTECTED]> writes:
...
>But it is certainly possible. And the PGP bug arises from the mistake that
>PGP originally made in not ensuring that all the additional decryption
>keys in the data-recovery field have to be signed to prevent the
>tampering.
>"The reason the researchers could discover it at all is because we publish
>the source code for peer review," Jones adds.
Yes, and now they have decided to no longer publish source code. Wonder
whom they are protecting?
> I guess I am still confused as to when the additional key is added. WAS
>the key for law officials hardcoded and thus transparent to the
>end user? Perhaps someone in touch with reality (being it that I am not)
>and with more understanding of PGP can explain what this "flaw" WAS....
No. IN the public key published by A, he could also include a line
saying "Please, when you send a message to my key, also encrypt the
message (or rather the secret key to the IDES/DES/... encrypted
message) also to the key B" Unfortunately, they forgot to make sure that
tkey B was signed by the private key A. Thus anyone could add to an one
elses public key A the request to also send it to any other key C, and
PGP would happily encode the message to both A and C. Thus I could
(somehow) change your public key on say the MIT server asking that all
messages to you also be sent to me, and anyone who downloaded your
public key from MIT and used PGP would copy all messages they sent to
you to me as well, so that I could decrypt them. This was a "bad thing".
It begs the question of how I managed to change your key on the MIT
server since the server usually demands that I sign all requests to
change key A with the private key A ( which I do not have). But bugs in
server software are not impossible.
------------------------------
From: "Olivier LARRIGAUDIERE" <[EMAIL PROTECTED]>
Subject: USB key storage
Date: Wed, 14 Mar 2001 22:41:40 GMT
Hi,
Any idea about an USB memory (like a dongle) for GnuPG key storage ?
Thanks for your answer.
------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: Quantum Computing & Key Sizes
Date: Wed, 14 Mar 2001 22:45:42 -0800
Bill Unruh <[EMAIL PROTECTED]> wrote in message
news:98jo1b$2o6$[EMAIL PROTECTED]...
> In <98jddg$jgi$[EMAIL PROTECTED]> "Simon Johnson"
<[EMAIL PROTECTED]> writes:
> >To be honest, QC probably wouldn't make much of a difference to
public-key
> >cryptography. All that would happen is this size of the modulo would be
> >increased.... computation time for signining documents etc... would be
> >unchanged because the speed of computation would have also increased
> >(obviously)
>
> This is wrong. IF one had a QC, then factoring the number is about
> equivalent to multiplying the factors together to get the number. Ie,
> encryption and factoring are of the same order in speed-- if you can
> encrypt it, the opponent can decrypt it just as fast. The encryption
> technique would be useless.
How does this work? Whats special about a quantum computer can it make
guesses or something???
Simon.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Analysis of PCFB mode
Date: 14 Mar 2001 23:27:24 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
I just took a look at PCFB mode:
http://csrc.nist.gov/encryption/modes/proposedmodes/pcfb/pcfb-spec.pdf
The proposal seems to suggest that it can be used to provide both
confidentiality and message integrity (when there is sufficient
redundancy in the plaintext). However, it seems to have a few
undesirable properties.
The proposal leaves two critical details unspecified:
- The redundancy scheme (for integrity) is not described.
- The parameter m, which describes the number of bits encrypted per
block cipher operation, is unspecified.
Both of these areas have pitfalls. Unfortunately, it is left up
to the implement to puzzle out these design choices for herself
(no guidance -- or even warning of the risks -- is provided in
the specification of the mode as proposed to NIST).
First, it seems difficult to choose m so that PCFB mode becomes
competitive. If m is too small, PCFB mode is inefficient. With
m=64, PCFB mode is already twice as slow as other integrity modes
(IACBC, OCB, XCBC, etc.), which suggests that there will be strong
pressure to choose m >= 64. However, when m is large, the
error-propagation mechanism has some perhaps-undesirable properties.
In particular, PCFB has only 128-m bits of internal state (when
used in decryption mode), so by the birthday paradox we can expect
to see collisions in the internal state after about 2^{64 - m/2}
blocks of ciphertext, which might raise questions about security.
So we could be stuck between a rock and a hard place in choosing m.
Second, PCFB mode is insecure when used with some redundancy schemes.
Consider what may be the most natural scheme of all: we append 128
zero bits to the message before encryption, and on decryption we check
that these bits have not been disturbed. Yet such a scheme is insecure
against chosen-plaintext attack: We can ask for the encryption of
the chosen message X || 0 || Y, and then truncate the ciphertext just
before the "Y" part. The result will be a valid encryption of X;
since the sender may never have authorized the transmission of X, this
is an integrity failure. It seems plausible that PCFB mode may be
secure under some other choice of redundancy scheme, but if history
is any guide, it would be prudent to step with considerable caution.
(There have been many similar proposals intended to provide integrity,
but almost all have since been broken. The only exceptions I am aware
of are a few recent modes that have been proven secure.)
------------------------------
Subject: Re: PGP "flaw"
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 14 Mar 2001 23:39:21 GMT
Bill Unruh <[EMAIL PROTECTED]> wrote:
> Yes, and now they have decided to no longer publish source code. Wonder
> whom they are protecting?
You can't help but think about that - first a serious(ish) security
problem is discovered, then a few months after patching that up they
stop releasing the source code.
/Tony... who... me... worried...
------------------------------
Subject: Re: USB key storage
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Date: Wed, 14 Mar 2001 23:44:11 GMT
Olivier LARRIGAUDIERE <[EMAIL PROTECTED]> wrote:
> Any idea about an USB memory (like a dongle) for GnuPG key storage ?
There are such things already (although the GPG-part I'm not so sure
about out in an "out of the box"-ish way).
/Tony
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: Crypto idea
Date: Wed, 14 Mar 2001 18:52:40 -0400
and the two categories?
You have to read what I had explained before.
[EMAIL PROTECTED] wrote:
>
> br <[EMAIL PROTECTED]> wrote:
> : Using the brute force, it's impossible for any cryptanalist to read
> : every output assuming the key x. But if you have the key it's then to
> : read any message. Btu the cryptanalysis can't imagine that the output is
> : "Ilov u " or Ay lovv u or etc...
> : How the cryptanalist could imagine before trying to attack my
> : cipher-text the way I had written I love you?
> : How the cryptanalist could imagine before trying to attack my
> : cipher-text the way I had create two types of characters that every
> : human can distinguish? There an infinite way to create 2 types.
> : Cryptanalisis is unarmed to attack my cipher.
> : Cipher based on spelling mistakes and two categories is unattackable.
>
> What if I wrote a program to interpret the text phonetically and compare
> it against a phonetic dictionary. Presumably, ilovu and aylovvu might still
> match "i love you", if you account for possibly pronouncing various letters.
>
> That might permit a brute-force attack.
> Mark
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: How good is the KeeLoq algorithm?
Date: Mon, 5 Mar 2001 11:32:30 -0800
At 64-bits there's no need for weak keys.
56-bit DES has been broken using second rate technology in 22 hours 15
minutes.
Expanding this, we get a MAXIMUM breaking time for KeeLoq of 237 days.
Considering that the algorithm is as you pointed out extremely small, it can
be even more massively parralelized. In fact at that small you could
probably manage 100x the parralelization that was used for DES, so you've
got basically a weekend job for breaking.
Personally I think that at this level of parrelelization custom ICs would be
the most useful, with a nice deep 500 segment pipe, giving 1 key per clock
throughput. Since it's so small this could be done in a matter of a few
thousand transistors (even Rijndael is only 15K if I remember correctly, so
it could be done smaller), considering that it is fairly standard to reach
above the 50 million transistor line per chip that's 3000+ testers per chip,
clocked at > 1GHz. A single chip would take 6 million seconds to search the
entire space. Take a thousand chips, that's about 2 hours. Of course I'm
leaving out the filter technology, but at 3000 encrypters/chip that leaves
~5 million transistors, more than enough space.
As to whether or not using fewer round would weaken it. It would decrease
the resistance to cryptanalysis, but if the attacker does something like the
one above it doesn't do anything, however it would increase the number of
encrypters that could be placed on a single chip.
Joe
"Søren A.Møller" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
>
> > I have looked at the KeeLoq algorithm in detail, and it appears to be
> > as secure as any 64-bit key 32-bit block algorithm could be. It is
> > well-suited for remote keyless entry, but for little else because
> > it is so very slow, using over 500 rounds.
>
> Thanks for the info.
>
> Yes, it is slow (28ms for decoding on a 4MHz (1 MIPS) PIC
> microcontroller), but it only needs something like 16 bytes of RAM (8 for
> key, 4 for data, 4 for misc) and 4 bytes of static look-up table (32
> bits) so it can be fitted into the smallest PIC microcontroller.
>
> Do you know if it has any weak keys?
> And if it is significantly degraded by use of fewer rounds? (I guess it
> is otherwise they would have used fewer rounds - right?)
>
> --
> Søren A.Møller
------------------------------
From: br <[EMAIL PROTECTED]>
Subject: Re: Crypto idea
Date: Wed, 14 Mar 2001 19:01:16 -0400
Factoring RSA help you to find the way to disclose the key, nothing
more.
I'm talking about cryptanalisis. You can't imagine before that I used
two categories.
If I use two categories without telling to my recipient that the ugly
laddy is 1 or 0, he can understand the difference between uggly laddy
and beautiful laddy. The computer no. A cryptanalist can't imagine
before attack what categories I had used unless he has the key. If he
try to test all the he has to see (physically) every ouptut.
So, it's impossible.
Even if he use all dictionaries.
David Schwartz wrote:
>
> br wrote:
> >
> > My idea it's like someone who don't know wich language I used.
> > But once the plain text deciphered with the appropriate key every human
> > being can read and understand Ay lovv u or Ilauv yu etc...
> > Before attack, cryptanalisis is helpless.
>
> If you are factoring an RSA key, what difference does it make what the
> plaintext looks like? I strongly suspect that you have no idea what you
> are talking about.
>
> DS
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Crypto security of pseudo-random sequences
Date: Mon, 5 Mar 2001 12:01:55 -0800
"Mok-Kong Shen" <[EMAIL PROTECTED]>
> If one has a statistically good pseudo-random sequence, e.g.
> one from the Mersenne Twister, and post-process it through
> the following methods:
> (1) Encryption with AES.
Qualifies. under the assumption that the PRSeq has some continuous quantity
of apparent entropy this will be added to the apparent entropy from AES. The
result is a sequence that will have a rather significant amount of apparent
entropy (provided that the AES key is never leaked). Further proof provided
by the fact that counter-mode is considered crypto-secure.
> (2) Hashing with SHA-1.
Same as the above, but assuming that SHA-1 is a cryptographically secure
hash, and provided certain assumptions about usage.
> (3) Using groups of n bits (e.g. n=24) to index the binary
> digits of Pi.
Does not qualify, this is a known mapping, it can then be reversed (to a
degree, analysis for the rest), this will give you the original stream,
which can be analyzed. Additionally this will add bias to the output.
> (4) Further processing any of the above by taking the parity
> of groups of m bits.
If the input is crypto secure, and at least as much data is thrown away
(uniformly) as is added by the parity, then yes this will be crypto secure.
Without throwing away data, the parity can be easily computed, it is
obviously trivial. By throwing away data at the same rate as parity
injection, you give the attacker who knows the whole stream the ability to
compute those missing bits, by the parity. If you discard at a rate greater
than the parity injection, you lose information which cannot be recovered.
Joe
------------------------------
** 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
******************************
