Cryptography-Digest Digest #864, Volume #11 Fri, 26 May 00 12:13:01 EDT
Contents:
Re: Another sci.crypt Cipher (Mark Wooding)
Re: Anti-Evidence Eliminator messages, have they reached a burn-out point? ("Hiram
Yaeger")
Re: PGP wipe how good is it versus hardware recovery of HD? (Guy Macon)
Re: RSA/PK Question ("Trevor L. Jackson, III")
Re: RSA/PK Question ("Trevor L. Jackson, III")
Re: list of prime numbers ("Jeff Moser")
Re: bamburismus ("Douglas A. Gwyn")
Re: Matrix key distribution? ("Douglas A. Gwyn")
Re: Is OTP unbreakable? ("Douglas A. Gwyn")
Read all my messages on alt.politics.org.cia .... a lots of the good information
about espionage, intelligence and issues ... (Markku J. Saarelainen)
Re: Base Encryption: Revolutionary Cypher (Mok-Kong Shen)
Q: OFB (Mok-Kong Shen)
Re: Retail distributors of DES chips? (Jonathan Thornburg)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Another sci.crypt Cipher
Date: 26 May 2000 12:50:45 GMT
tomstd <[EMAIL PROTECTED]> wrote:
> The chance of getting these keys is 2^-96 right? Hmm I can live
> with that. Think I should include the round counter
> to 'counter' the weak keys?
>
> Thanks for looking at my cipher.
I have a 16-round differential characteristic for your complete cipher,
with probability approximately 2^{62.5}.
The characteristic evolves like this:
0: 00000000 00010000
1: 00010000 00000000 (01[1] -> 03[2], p = 4)
2: 00000300 00010000 (03[2] -> 01[1], p = 6)
3: 00000000 00000300
4: 00000300 00000000 (03[2] -> 01[1], p = 6)
5: 00010000 00000300 (01[1] -> 03[2], p = 4)
6: 00000000 00010000
7: 00010000 00000000 (01[1] -> 03[2], p = 4)
8: 00000300 00010000 (03[2] -> 01[1], p = 6)
9: 00000000 00000300
10: 00000300 00000000 (03[2] -> 01[1], p = 6)
11: 00010000 00000300 (01[1] -> 03[2], p = 4)
12: 00000000 00010000
13: 00010000 00000000 (01[1] -> 03[2], p = 4)
14: 00000300 00010000 (03[2] -> 01[1], p = 6)
15: 00000000 00000300
16: 00000300 00000000 (03[2] -> 01[1], p = 6)
17: 00010000 00000300
The hex numbers on the left are the input differences to each round.
The thing on the right is the differential through the S-box and
permutation which it exploits, given as input and output differentials,
with the S-box to which each pertains. The probabilities given are
fractions of 256.
As you can see, it's basically a three-round iterative characteristic,
which moves a difference between S-boxes 1 and 2.
While this implies that almost the entire codebook must be recovered to
perform the attack, I think it suggests that TC1 has a low security
margin. I recommend against its use.
Don't look to your S-boxes for the problem: look to your diffusion.
-- [mdw]
------------------------------
From: "Hiram Yaeger" <no@email>
Subject: Re: Anti-Evidence Eliminator messages, have they reached a burn-out point?
Date: Fri, 26 May 2000 06:47:10 -0700
Crossposted-To: alt.privacy,alt.privacy.anon-server,alt.security.pgp
"Steve" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 25 May 2000 20:03:18 +0100, EE Support
> <[EMAIL PROTECTED]> wrote:
>
> >Hi,
> >
> >EE Tech Support here.
> >
> >Greetings to those genuine people who continue to support our
> >wonderful Evidence Eliminator software.
>
> Let's see, its closed source software, its makers brag endlessly
> on endorsements from unqualified hucksters, and they make
> unrealistic claims that they can't back up. That eliminates
> "security" from any reasonable description of Evidence
> Eliminator.
>
> And it obviously has nothing to do with PGP.
>
> I wonder when these spammers will realize that alt.security.pgp
> does not exist to serve as a private advertising forum for their
> product?
>
>
>
> Steve
What I found amusing was their greeting to "genuine people" that support
their product. I suppose those of us that don't support spamming newsgroups
with off-topic nonsense aren't "genuine people," and are instead facsimiles,
or perhaps cloned drones whose only goal is to attempt to put EE out of
business.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: PGP wipe how good is it versus hardware recovery of HD?
Date: 26 May 2000 09:55:47 EDT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>I have a program called shredder which I believes overwrites a file 7
>times with random data to try and prevent hardware recovery of deleted
>files aka the story in the WSJ. Does PGP wipe function do this or does
>it only overwrite once?
If history is a guide, you will now read a claim that single pass
wipes are perfect. This ignores the possibility that recovery is
possible and that those who can do the recovery aren't telling.
There is even the possibility that they hire people to post in
this newsgroup claims that single pass wipes are perfect...
Here is what we know:
No one has published results of a sucessful recoivery of a single
pass wipe to this newsgroup.
There is a paper that shows how, in theory, such data is
recoverable. The internet version has pictures of bits that
were not completely overwritten.
Some versions of PGP wipe on some operating systems don't even do
a single pass wipe. Maybe shredder won't either.
Some caching disk controllers turn multipass overwrites into
single pass overwrites withou telling you.
The Military doesn't trust any sort of overwriting scheme.
They use the baest available multipass overwriting software
then physically destroy the drive. Do they know something,
or are thet just being careful?
------------------------------
Date: Fri, 26 May 2000 10:45:00 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > No one who knows what they are doing will use 8kbit RSA keys
> > saying "they must be more secure then 2kbit keys". If we
> > *can't* factor 2kbit keys, then it doesn't matter right?
>
> WRONG! This has been explained to you before, but you persist in
> burying your head in the sand and refusing to listen. I'll try ONE
> more time.
>
> For security, you have to look at two things: first of all, the
> period of time for which the information you're working with will be
> valuable.
Typically this period is the sum of two sub-periods, one for the lifetime of
the cipher and the other for the lifetime of information.
The operational lifetime of the cipher should include several sub-sub periods
covering a) the period in which system designs specify the cipher as a
component, b) the period of time in which such systems are produced, and c)
the period of time in which such systems remain in the field. While (a) may
be reasonably related to the security provided by the cipher, often (b) is
controlled by economic and technical (compatibility) factors. Usually (c) is
much longer than "reasonable".
The lifetime of information can be very hard to predict because reasons for
continued secrecy may develop during the lifetime of the info. This coupled
with the asymmetry of failure to provide enough strength versus "failure" by
providing "too much" strength leads to the conclusion that it is not useful to
declare a terminal date for ciphers.
> Second, based on that, you must choose a cipher (including
> key size) that you believe will remain secure for at least that long.
>
> For example, if you want some information to remain secure for at
> least the next 50 years, you'd _better_ not depend on an RSA key of
> 768 bits, even though that's (AFAIK) unbreakable at the present time.
> In 50 years, an average hand-held calculator is likely to have more
> than enough resources to break a 768-bit key.
>
> For MOST purposes, picking a key size cannot and should not be based
> strictly upon what is possible right now. Key sizes (and ciphers in
> general) must be picked to give a reasonable degree of assurance of
> security for some period of time. Since we don't know what's going
> to happen in the future, it's MUCH better to do so conservatively
> than otherwise.
>
> It's true that some people go overboard with this, but there can
> still be _excellent_ reasons to go well beyond what is necessary to
> maintain security at the present time.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
------------------------------
Date: Fri, 26 May 2000 10:51:18 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: RSA/PK Question
tomstd wrote:
> In article <8gjjh2$a7c$[EMAIL PROTECTED]>, David A Molnar
> <[EMAIL PROTECTED]> wrote:
> >tomstd <[EMAIL PROTECTED]> wrote:
> >> People seem to forget that theoretical does not always mean
> >> practical. Yes theoretically your stmt may be true, but to
> >> actually *implement* the attack is not possible.
> >
> >Not possible toay. The charts at cryptosavvy and elsewhere
> represent
> >the efforts by various people to estimate what may be possible
> tomorrow.
> >Perhaps this is an odd notion of "possible," but it seems like
> what
> >we have to go on short of using info-theoretically secure
> systems
> >(and even then we have the wonderful world of implementation
> failures
> >to look forward to).
>
> The world is comming to an end, the end is near.
>
> Realistically, 1024 bit numbers normally can't be factored now.
> The technology won't be around for a bit, so I don't see the
> problem with using 768-1024 bit numbers.
Try a concrete example. Consider building a system that will be used for 30
years. The information handled by that system has a minimum lifetime of 50
years. So in 2030 your system will have to protect data until 2080.
Do you think 768-1024 bit numbers will be safe in 2080? That's almost twice as
far from now as the start of general purpose computing. How far have we come
since 1960? Are we moving as fast or faster now than we have, on average, over
the last 40 years?
This kind of example is why people think "If I take everything I can possibly
get, I'll almost have enough." ;-)
------------------------------
From: "Jeff Moser" <[EMAIL PROTECTED]>
Subject: Re: list of prime numbers
Date: Thu, 25 May 2000 11:57:53 -0500
> I don't know if this is public domain or not, but can we get a list
> with the (recent) prime numbers (up to 150 digits)?
>
This list would be huge to be conclusive. Record primes have upwards of huge
exponents of two plus or minus 1.
As for (relatively) small primes.. The first 150 digit one is
1000000000000000000000000000000000000000000000000000000000000000000000000000
00
0000000000000000000000000000000000000000000000000000000000000000000000067
(10^150 + 67)
the next few are
10^150 plus...
427
771
1323..
there are an unbelievable amount just in this small range (about 498 bits)
Perhaps I misinterpreted your question.. feel free to repost
Jeff
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: bamburismus
Date: Fri, 26 May 2000 14:13:00 GMT
John Savard wrote:
> Although that is not terribly definite, in my simplicity I would
> tend to consider such a thing an injudicious revelation even so.
Which part? (There were three.) That 3DES seems to be secure
enough at the moment? That is widely believed anyway. That
3DES is not the only cryptosystem in use? That is well known.
That 3DES might have been susceptible to cryptanalysis had my
research project panned out? Absent a proof otherwise, that's
the sort of thing you should assume of any cryptosystem.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Matrix key distribution?
Date: Fri, 26 May 2000 14:04:11 GMT
Michael Brown wrote:
> Are there any other matrix encryption things around?
The problem is that matrix methods are inherently highly linear
and thus simple algebraic manipulations can be used to crack them.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Is OTP unbreakable?
Date: Fri, 26 May 2000 14:24:35 GMT
> > The OTP does not offer any authentication.
Greg wrote:
> How rediculous. OTP offers the same level of authentication as
> most other private keys in a public key cryptosystem. If you have
> the key, then you can sign the document. That is all authentication
> means.
Authentication is more than that. For example, in the OTP
scenario, the encrypted message can be intercepted, a guess
made as to some portion of the probable plaintext (for example
a stereotyped beginning such as "For information only."),
that portion of the key recovered, and a different plaintext
substituted (e.g. "For immediate action."). The legitimate
receiver has no way to know that the message is not what the
legitimate originator sent. With a proper authentication
scheme, such spoofing would almost certainly be detected.
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.security,comp.security
Subject: Read all my messages on alt.politics.org.cia .... a lots of the good
information about espionage, intelligence and issues ...
Date: Fri, 26 May 2000 15:08:09 GMT
Read all my messages on alt.politics.org.cia .... a lot of the good
information about espionage, intelligence and issues ...
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Base Encryption: Revolutionary Cypher
Date: Fri, 26 May 2000 17:30:32 +0200
Tim Tyler wrote:
> You can probably observe avalanche in one base, and not in another -
> though changing base usually affects diffusion /mainly/ in one direction.
>
> I.e., if you change from base 10 to base 11, flip a low order digit, and
> then convert back, the upper digits are likely to remain unchanged -
> unless the lower digits happen to all be nines or all zeros.
>
> However, if you do the same, and flip a more significant digit, the result
> on the original digits after converting back will be more widespread
> chaos.
When one talks about avalanche (without qualification), one commonly
means the general case, i.e. not restricting to a particular region of bits.
So if avalanche is observed or not observed in one base (the first with
the existence and the second with the all quantor) the same must hold
in the other base (possibly at different intensity, though), I believe.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: OFB
Date: Fri, 26 May 2000 17:32:07 +0200
If one runs a block cipher in n-bit OFB mode with n equal
to the block size, then one is doing repeated encryption
of an IV. The output eventually repeats, i.e. the sequence
of the outputs must have a period.
Question: Are any literatures about the period lengths for some
well-known ciphers, e.g. DES, available? Thanks.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Retail distributors of DES chips?
Date: 26 May 2000 17:47:51 +0200
Someone (who if I've unwrapped the nested quoting correctly might have
been Mark Wooding) wrote:
>> Yes, but the point is that, in theory, DES is completely deterministic.
>> If you have a DES chip, you can feed known keys and plaintexts in it,
>> and verify that you get the right answers against some other known and
>> trusted implementation. You can even give it `trick questions' every
>> now and then while it's in production use, checking its results, to make
>> sure it's not randomly deciding to emit leaked key material instead of
>> giving the right answers every now and then. I'd hope that most serious
>> users of black-box cryptography hardware or software did something like
>> this.
In article <[EMAIL PROTECTED]>,
David Hopwood <[EMAIL PROTECTED]> replied:
>Testing isn't sufficient. Consider:
>
> DES'[K](P) = DES[K](P), if P != backdoor
> = K, if P == backdoor
>
>Then with a single chosen plaintext, the key is revealed. Assuming the
>backdoor plaintext is chosen randomly, no amount of testing that takes
>less than 2^63 expected work will find it.
David is of course quite right. For a nice illustration of the same
point, permit me to repost again, the following (highly amusing as well
as factually correct) message by Henry Spencer from the Linux-IPsec
mailing list:
## http://www.sandelman.ottawa.on.ca/linux-ipsec/html/1999/09/msg00240.html
_________________________________________________________________
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread
Index]
Re: linux-ipsec: Intel IPSEC accelerator gives 3DES protected 100Mbit Ethernet
_________________________________________________________________
* To: Linux IPsec <[EMAIL PROTECTED]>
* Subject: Re: linux-ipsec: Intel IPSEC accelerator gives 3DES
protected 100Mbit Ethernet
* From: Henry Spencer <[EMAIL PROTECTED]>
* From: [EMAIL PROTECTED]
* Date: Thu, 16 Sep 1999 10:48:52 -0400 (EDT)
* In-Reply-To: <[EMAIL PROTECTED]>
* Reply-To: [EMAIL PROTECTED]
* Sender: [EMAIL PROTECTED]
_________________________________________________________________
William H Geiger writes:
> I don't know if you still follow the CP list but we have
> been having a long debate on the trustworthiness of Intel
> hardware, especially their RNG...
At first I thought this was pretty much a non-issue here. The problem
with the RNG is that it's so hard to decide whether its output is "really"
random. But 3DES is a deterministic transform which can be tested against
other implementations, so you can easily establish whether the chip is
really doing 3DES or not.
Alas, then I got to thinking. Suppose one built a 3DES accelerator chip
so that, if and only if:
(a) the chip is doing near-continuous encryptions at high speed, and
(b) the keys are changing every packet or two, and
(c) the chip detects -- via a simple mechanism like a little hash table --
a key which has appeared before, recently, and
(d) this key has not been marked "compromised" in the hash table, and
(e) an internal 16-bit packet counter is all-1s,
then
(!) mark the key compromised in the hash table, XOR the key with the
string "GOTCHA, YOU OPEN-SOURCE WEENIES -- NSA RULES!", prefix it with a
random-looking constant bit pattern, and sprinkle the resulting bits into
the encrypted data, in a haphazard but deterministic pattern.
This is, of course, an encryption error. But rules (a)-(e) make it
essentially irreproducible, so it won't happen a second time (and will be
quite difficult to reproduce even in a test setup). Almost certainly it
will get written off as a random error, and the affected packet will be
re-processed correctly and re-sent, and all will be well.
Except that an eavesdropper on the high-speed wire just looks for the
constant bit pattern in the right places in a packet, and (almost) every
time he sees it, he's nabbed an encryption key.
There's no limit to the complexity that can be added -- especially if
you're willing to consider active wiretapping, with the chip going into
this mode only if it sees (say) an ICMP ping with the right data in it --
to defeat attempts to find this sort of thing on the test bench.
I fear I agree with William; nothing short of peer review of the hardware
design makes such a device trustworthy.
Henry Spencer
[EMAIL PROTECTED]
([EMAIL PROTECTED])
-
This is the [EMAIL PROTECTED] mailing list. It is a
restrict-Post filtered version of [EMAIL PROTECTED]
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
Seen on usenet:
Q: "If we're not supposed to eat animals, why are they made of meat?"
A: "If we're not supposed to eat people, why are they made of meat?"
------------------------------
** 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
******************************
