Cryptography-Digest Digest #540, Volume #12 Sat, 26 Aug 00 08:13:01 EDT
Contents:
Re: "Warn when encrypting to keys with an ADK" (jungle)
Re: blowfish problem ("Kelsey Bjarnason")
7 mil, how this usage of PGP has been calculated ? (jungle)
Re: PROMIS-software for worldwide spy network by US/Isreal (Mok-Kong Shen)
Re: PRNG Test Theory (Mok-Kong Shen)
Re: Best way! (Mok-Kong Shen)
Re: 1-time pad is not secure... (Tim Tyler)
cryptlib ("R�mi FOREST")
Re: DeCSS ruling -- More ("Stou Sandalski")
Re: DES: Say it or spell it? (Newbie question) ("Richard Bembridge")
You _DONT_ want a quantum computer. ("Detonate")
PGP 6.5.8 test: That's NOT enough !!! ("Michel Bouissou")
stegonographic overuse ("Detonate")
Re: PROMIS-software for worldwide spy network by US/Isreal ("Stou Sandalski")
Re: DeCSS ruling -- More (No User)
Re: stegonographic overuse ([EMAIL PROTECTED])
Re: PGP 6.5.8 test: That's NOT enough !!! ("JL")
----------------------------------------------------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Sat, 26 Aug 2000 03:55:37 -0400
help me ...
how should I understand 4 keys provided ?
which key is tempered & which has correctly added ADK ?
assuming that I will have only these 4 public keys & this would be the case
when I will receive them from owner ...
which public key can not be identified [ by normal available PGP futures ] as
the tempered ADK ?
when I'm importing any of these 4 keys, I see without any doubt which key has
ADK ...
therefore where is the problem at the key import ?
I can refuse to import any key with ADK attached, this is simple ...
in fact, every user can reject ADK keys, where is the problem ?
"S.R. Heller" wrote:
====
> <http://www.oz.net/~srheller/spgp/bin/testkeys.asc>
>
> The keys include private keys, which all have the passphrase
> "testing".
>
> Steve H.
------------------------------
From: "Kelsey Bjarnason" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Sat, 26 Aug 2000 01:27:08 -0700
[snips]
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 24 Aug 2000 19:01:58 -0700, Spud <[EMAIL PROTECTED]>
wrote:
> >The only disagreement involved was my disagreeing with arguments that did
> >absolutely nothing to actually resolve the issue. For example, the
comments
> >about memcpy; they didn't matter, because the requirements would have
held
> >true in either case, so the introduction of memcpy added absolutely
nothing
> >in answering the question.
>
> How so? If memcpy copied only half of every 16 bit byte in your example
> implementation, due to characters being only 8 bits wide,
Well, let's see what we've got.
6.2.5
[#4] Values stored in objects of any other object type
consist of n�CHAR_BIT bits, where n is the size of an object
of that type, in bytes. The value may be copied into an
object of type unsigned char [n] (e.g., by memcpy);
Note that "size in bytes" is open to some interpretation (again, within the
confines of this hypothetical compiler; we've ascertained elsewhere that
yes, char and byte are synonymous, so this discussion is _purely_ abstract).
The implementation in question uses 16-bit bytes, 8 bit chars, and 32-bit
ints... but defines sizeof(char) as 1; that means that sizeof(int), if
measured in chars, must be 4. Can it do this? Certainly.
If we do _not_ assume an equivalence, the implementation is free to chop
things up as it sees fit, as long as code still works. So when you alias
your int by a pointer-to-unsigned-char, for example, it requires _four_
accesses to retrieve the whole value. When you memcpy, if requires four
reads to retrieve the value, four to write it.
>From the code's perspective, char and byte may as well be the same; they
can't tell the difference. However, that's _strictly_ within the confines
of the code; as soon as it starts talking to the outside world, things get
wierd.
> then it would clearly
> fail to be capable of copying the values of data objects which take
advantage
> of the full 16 bits.
Except there can be no such objects _internal_ to code based on the
implementation; only when accessing things _outside_ it, such as files
written by programs which use full 16-bit bytes. Internally, the code
cannot produce 16-bit objects (or, rather, objects composed of full 16-bit
bytes).
> Perhaps in your example implementation, *no* type uses more then 8 bits of
any
> 16 bit byte. If that is the case, then, effectively, the C implementation
has
> *defined* bytes as being 8 bits wide.
Actually, it defined chars as being 8 bits wide; the question was, how do we
know that, in fact, this means that _bytes_ are 8 bits? The memcpy
argument, for example, fails, because "The memcpy function copies n
characters from the object..." - note that it says "chars", not "bytes".
Since in the implementation in question this can still be accomplished,
memcpy has absolutely no benefit in actually determining the similarity of
chars and bytes.
> That these bytes are stored in wider
> units of actual memory is irrelevant; storage bits that are not visible to
the
> C program effectively do not exist.
Internally, that would be the case; as I noted previously, the code itself
would be absolutely unable to tell the difference one way or the other - as
long as it was *only* the code involved.
Now, I create a Pascal program that writes "file.dat" by using Pascal's
equivalent of fputc()... but using the full 16-bit width of the byte. How
do you read this in with your C code compiled in this implementation?
fgetc() returns an unsigned char converted to int, not a byte, leading to
the conclusion that in order to make it read the file, fgetc() has to be
called twice for every byte in the file - and let's not even think what that
implies for seeking, or for files opened for read and write - or it has to
simply discard anything beyond 8 bits worth of data.
So, if byte and char actually differ, then things can get wierd, even though
within the confines of the code itself the differentiation doesn't, and in
fact cannot, matter.
Again... yes, char and byte are synonymous, so this discussion is _purely_
abstract.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: 7 mil, how this usage of PGP has been calculated ?
Date: Sat, 26 Aug 2000 04:27:28 -0400
PGP is used by 7 million people worldwide, according to Wallach ...
how this usage of PGP has been calculated ?
any help ?
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
Date: Sat, 26 Aug 2000 11:25:37 +0200
Mike Andrews wrote:
>
> Systems that handle any sort of classified data need to be
> completely isolated from any connection to any insecure network.
> That's Rule #1
The German magazine Spiegel has recently an interesting
article reporting that a Swiss firm has built a computing
centre in a vault inside a mountain in a militarily guarded
area which is thus physically extremely safe. Customers may
deposit their ultra-secret data there which are then on-line
accessible at a moderate cost of some 20 dollars for 2 GB
of storage monthly.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Date: Sat, 26 Aug 2000 11:25:46 +0200
[EMAIL PROTECTED] wrote:
>
> Since any PRNG test can tell when a stream of bits is empiracly random,
> that should suggest that any PRNG test can be turned into a PRNG itself.
To my humble knowledge such a test tells you (with respect to
a certain 'pattern' and at a certain confidence level) whether
non-randomness is likely to be there, nothing more. Passing
a multitude of different tests of extensive outputs from a
source enhances the expectation that the source approximates
well a really random one so that the opponent very likely may
not be able to know how to exploit any weakness that is not
yet detected by you.
Your claim that any PRNG test can be turned into a PRNG is
not understandable for me, especially when several tests
are considered. Take for example the frequency test and
the serial test (at lag 1). Could you please elaborate on
your idea in some concrete manner with a good example
of generation of a number of successive bits? (Even for a
single test you have yourself shown the difficulty, if I
don't err. You want the resulting output to pass all tests
being considered simultaneously, don't you?)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best way!
Date: Sat, 26 Aug 2000 11:29:04 +0200
Big Boy Barry wrote:
>
> What is the best way to send encrypted email. Encrypted email that
> cannot be cracked by any means. I know for sure that PGP is not secure. So
> please give me the best way to send encrypted email. Thank you.
A first step of the best way is to build a quantum computer,
I presume.
M. K. Shen
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: 1-time pad is not secure...
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 Aug 2000 09:19:22 GMT
S. T. L. <[EMAIL PROTECTED]> wrote:
: TT>EPR experiments "pretty much" rule out the idea that physics
: TT>depends only on local interactions.
: Shows you what you know. Spooky action at a distance is D-E-A-D, no matter
: what you think. It just looks like it isn't. Hence the term spooky. Duh.
I've looked into this, and you appear to be essentially correct -
I was expressing a popular - but now apparently mistaken - view.
Pages such as http://users.aber.ac.uk/cat/intro.htm seem to tell today's
story - and to my suprise - indeed astonishment - it's quite a turn around
from the days of the Apsect experiment.
Note that I quoted "pretty much" in my statement. I've actually been a
fan of local explanations for physical phenomena for some time - even
citing Fredkin's 1980 "Digital Mechanics" paper on this thread.
I've provided pointers to local theories that demonstrate that
local explanations remain /possible/ - despite Aspect's work. The
supposed non-locality of quantum physics has one of two stumbling
blocks to digital mechanics - the other being relativity.
Lastly, any remaining followers of this now-off-topic thread may also
find some interest in this:
``Actual realisations of EPR experiments do not demonstrate non-locality.
A model is presented that should enable non-specialists as well as
specialists to understand how easy it is to find realistic explanations
for the observations. The model also suggests new areas where realistic
(``hidden-variable'') models can give valid predictions whilst quantum
mechanics fails. It offers straightforward explanations for some
anomalies that Aspect was unable to account for, providing perhaps the
first experimental evidence that a hidden-variable theory can be superior
to quantum mechanics. The apparent success of quantum mechanics in
predicting results is shown to be largely due to the use of
unjustifiable and biased analysis of the data. Data that has been
discarded because it did not lead to a valid Bell's test may give
further evidence that hidden variables exist.''
From: http://xxx.lanl.gov/abs/quant-ph/9611037
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: "R�mi FOREST" <[EMAIL PROTECTED]>
Subject: cryptlib
Date: Sat, 26 Aug 2000 11:53:24 +0200
Does anyone here use cryptlib
(http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ ) for programming ?
How secure is it ?
Thanks.
R�mi.
------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: DeCSS ruling -- More
Date: Sat, 26 Aug 2000 03:21:56 -0700
(Off topic really) Yea just like with the microsoft case (I dislike
microsoft... maybe even hate them... as much as the next guy... however the
rulling was pretty wack)... the government (once again) did not get it...
its quite sad actually, because big corporations can afford to fuck everyone
and then convince the technicaly ignorant judicial branch whatever they
want... well I guess nothing has changed really? big corps have been, and
_always_ will fuck everyone and get away with it... hehe democracy is great
huh?
but DeCSS can't be stoped.... no matter what they try to do they can't shut
every server down that has it... and confiscate every copy of the code...
despite the fact that the US has very big influence in the international
community, these courts have no jurisdiction in countries outside north
america.... and even if they put some muscle into it their are countries who
don't give a god damn about what the US wants and would allow servers
mirroring the code... if all else fails... their's still Sealand eh? I
wonder what the MPAA will do if someone prints 500K copies of the source
code and posts them all over san francisco... seatle... new york.... hmmm
Stou
"David C. Barber" <[EMAIL PROTECTED]> wrote in message
news:8o1joc$26p7$[EMAIL PROTECTED]...
> What was astonishing (showing the judge's lack of understanding) is when
you
> read the judge's ruling. In the first couple of paragraphs the judge
refers
> to CSS as a Copy Protection Scheme.
>
> As anyone here should know, CSS does *not* prevent copying. You can make
as
> many image copies as you want (or given the high price of DVD-RW, as many
as
> you can afford :^). The encrypted file may be copied as many times as you
> wish, giving perfect digital, encrypted copies down to the n-th
generation.
> And all of these copies play back just the same in licensed players.
>
> CSS IS NOT COPY PROTECTION!
>
> And the judge clearly doesn't get it.
>
> Yeah, it's frustrating, since the whole ruling is that DeCSS is in
violation
> of the DMCA because it breaks copy protection, when it does no such thing.
>
> *David Barber*
>
>
>
------------------------------
From: "Richard Bembridge" <[EMAIL PROTECTED]>
Subject: Re: DES: Say it or spell it? (Newbie question)
Date: Sat, 26 Aug 2000 11:30:20 +0100
I disagree.
I am relying on the information you have posted in saying this:
If "ae" is pronounced as "e" (as in your examples) then AES should be
pronounced as "ees", not "es".
:-)
"S. T. L." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> <<Unlike AES, for example.>>
>
> Well, "ae" is pronounced as just "e" (aether, ether, haemo..., hemo...,
> encyclopaedia, encyclopedia, etc.), so AES reduces to ES, which is
obviously
> pronounced "S". :-P Even easier than DES!
>
> -*---*-------
> S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
> My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
> Optimized pngcrush executable now on my Download page!
> Long live pngcrush! :->
------------------------------
Reply-To: "Detonate" <[EMAIL PROTECTED]>
From: "Detonate" <[EMAIL PROTECTED]>
Subject: You _DONT_ want a quantum computer.
Date: Sat, 26 Aug 2000 18:42:17 +0800
_NONE_ of your games will work. (!)
------------------------------
From: "Michel Bouissou" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: PGP 6.5.8 test: That's NOT enough !!!
Date: Sat, 26 Aug 2000 12:49:17 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
I've just tested the "ADK-bug-fixed" PGP 6.5.8 against Ralf's B1
forged key that holds a faked ADK.
Where previous versions would show this key as having an ADK, and use
the forged ADK, the "fixed" PGP 6.5.8 shows the forged key as being a
normal, valid key, without any ADK.
PGP 6.5.8 will not use the forged ADK for encryption, and will just
behave as for a normal key.
Well, okay, it "fixes" the bug.
BUT IT DOESN'T WARN YOU IN ANY WAY THAT THE KEY YOU'RE USING HAS BEEN
FORGED. You just see a valid key and the forged ADK is ignored.
So:
- - You don't know the recipient's key has been victim of an attack;
- - You don't know that this key remains a potential danger for users
that still have previous versions of PGP.
Actually with PGP 6.5.8, you have LESS CHANCES to ever detect that a
key was forged, than you had with previous vulnerable versions.
That's no good folks.
Waiting for 6.5.9 that will display a BIG WARNING that an ADK sits
where it shouldn't on a given key.
- --
[EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: Corrigez le bug PG ADK. Installez PGP 6.5.8 ou plus recent.
iQA/AwUBOaeSnY7YarFcK+6PEQJUCACdFPt9KmCr+ImmCdpYt8i6XUlcmYUAnRRj
+OXfvsBkFugPmzNIlCaVO2N5
=iGL6
=====END PGP SIGNATURE=====
------------------------------
Reply-To: "Detonate" <[EMAIL PROTECTED]>
From: "Detonate" <[EMAIL PROTECTED]>
Subject: stegonographic overuse
Date: Sat, 26 Aug 2000 18:49:42 +0800
embedding an encrypted message into a gif file is fine and all, but if
somebody was eavesdropping on my email and i was repeatedly sending gifs,
they'd realise soon enough that there are messages being stored in the
gif's... embedding the message in various different formats probably won't
help too much more either. im very new to all this, but would it be true
that, like fatty foods, steganography is best used in moderation? :-) ...
anyone want to throw their 2c at me?
------------------------------
From: "Stou Sandalski" <tangui [EMAIL PROTECTED]>
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
Date: Sat, 26 Aug 2000 03:48:11 -0700
"Mok-Kong Shen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Mike Andrews wrote:
> >
> > Systems that handle any sort of classified data need to be
> > completely isolated from any connection to any insecure network.
> > That's Rule #1
>
> The German magazine Spiegel has recently an interesting
> article reporting that a Swiss firm has built a computing
> centre in a vault inside a mountain in a militarily guarded
> area which is thus physically extremely safe. Customers may
> deposit their ultra-secret data there which are then on-line
> accessible at a moderate cost of some 20 dollars for 2 GB
> of storage monthly.
>
> M. K. Shen
Yea Sealand's (www.sealandgov.com) (idea is even better... they provide
you with a government-interference-free, data storage... safe too... not in
a mountain but its supposed to have like machine guns and shit when its
finally online... hehe won't do much good against an american cruise missile
(once of course the US decides Sealand is bad for democracy)
peep out these links:
http://www.havenco.com/
http://www.wired.com/news/business/0,1367,36749,00.html
http://www.wired.com/news/politics/0,1283,36756,00.html
http://www.wired.com/news/business/0,1367,36749,00.html
this ones good too
http://www.wired.com/news/politics/0,1283,37573,00.html
------------------------------
Date: Sat, 26 Aug 2000 05:20:28 -0500
From: No User <[EMAIL PROTECTED]>
Subject: Re: DeCSS ruling -- More
In article <rWMp5.3769$[EMAIL PROTECTED]>
"Stou Sandalski" <tangui [EMAIL PROTECTED]> wrote:
>
Okay, here is the game... After all this is sci.crypt. Both Deja-
News
& Alta Vista have removed the source from their servers. Someone
needs
to figure out a 'encryption method' that would convert the C source
code
to something that would not look like the original document, but not
be
seen as binary so it would be stored on Deja-News and its ilk.
Instead of
ASCII armour we need an 'English' armoured scheme.
Documents would be stored on these servers and no-one would know what
they
really represent. The keys could be distributed to convert them
back. This
would not need to be a high security scheme, just enough to get it
through a
binary scanner to get it stored.
Any idea?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: stegonographic overuse
Date: Sat, 26 Aug 2000 11:49:27 GMT
Detonate <[EMAIL PROTECTED]> wrote:
> embedding an encrypted message into a gif file is fine and all, but if
> somebody was eavesdropping on my email and i was repeatedly sending gifs,
> they'd realise soon enough that there are messages being stored in the
> gif's... embedding the message in various different formats probably won't
> help too much more either. im very new to all this, but would it be true
> that, like fatty foods, steganography is best used in moderation? :-) ...
> anyone want to throw their 2c at me?
Yes, no, maybe? Sending large amounts of jpegs may simply indicate
that you and your friends are going to go blind at an early age. ;)
Simply put, the ideal situation would be to make the traffic look
"normal" to an outsider. If you normally send large amounts of
pictures anyway, there'd be no reason to suspect anything. Especially
if you throw in some innocuous text messages too.
A better bet, though, is probably to encrypt all of your mail, images
included. That way, decrypting it only yields the "picture" where most
people will stop.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: "JL" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: PGP 6.5.8 test: That's NOT enough !!!
Date: Sat, 26 Aug 2000 12:07:36 GMT
"Michel Bouissou" <[EMAIL PROTECTED]> a �crit dans le message news:
8o87bf$p7m$[EMAIL PROTECTED]
> That's no good folks.
Indeed. NAI is showing a total misunderstanding of the issue, and discredits
itself even more with this bug-fix release.
JL.
------------------------------
** 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
******************************
