Cryptography-Digest Digest #538, Volume #12 Fri, 25 Aug 00 21:13:01 EDT
Contents:
Re: Bytes, octets, chars, and characters (Richard Heathfield)
Re: PROMIS-software for worldwide spy network by US/Isreal (Mike Andrews)
Re: PROMIS-software for worldwide spy network by US/Isreal ([EMAIL PROTECTED])
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Crypto Coprocessor on Javacard (Shawn Willden)
Re: Bytes, octets, chars, and characters (Michael Rubenstein)
Re: "Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: "Warn when encrypting to keys with an ADK" (S.R. Heller)
Re: Test on pseudorandom number generator. ("Paul Pires")
Re: Bytes, octets, chars, and characters (Ben Ketcham)
Re: Sending Messages in Morse Code (John Savard)
Re: Bytes, octets, chars, and characters (Mark McIntyre)
Re: Bytes, octets, chars, and characters (Eric Smith)
PRNG Test Theory ([EMAIL PROTECTED])
Best way! ("Big Boy Barry")
Re: An interesting cryptographic problem (Daniel Newby)
----------------------------------------------------------------------------
Date: Fri, 25 Aug 2000 22:24:42 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
"Douglas A. Gwyn" wrote:
>
> "Bruce G. Stewart" wrote:
> > Hey, c could free up a key word by using "signed signed" instead of
> > "unsigned".
>
> If it weren't for the historical ambiguity about whether plain
> "char" is signed or unsigned, we could dispense with "signed"
> altogether, since it's the default for all other integer types.
Yes, but that would give the EBCDIC people a real headache, since (in
EBCDIC), the alphabet (and digits) have codes > 127 (I'm thinking of the
rule that what we might call 'normal' characters must have a positive
value - I can't find it in the C99 Standard but I'm reasonably sure it's
there). I suppose they could get around that by setting CHAR_BIT to 16,
if they were prepared to make the necessary hardware changes.
Having said that, I have no particular problem with giving the mainframe
guys a hard time, now that I am no longer one of their number. :-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
65 K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html (32
to go)
------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
Date: Fri, 25 Aug 2000 21:33:33 GMT
Scripsit Mok-Kong Shen <[EMAIL PROTECTED]>:
: If a security/intelligence agency is not careful enough
: to examine whether the software used is safe, then, if
: unfavourable things happen, these are well 'deserved'.
: See also my follow-ups in the thread 'Serious PGP v5 &
: v6 bug!'.
It's worse than that! What was a computer that handled Top Secret
data doing connected to _ANY_ sort of external network -- even
the Public Switched Telephone Network? It makes no sense at all.
Systems that handle any sort of classified data need to be
completely isolated from any connection to any insecure network.
That's Rule #1
If the Canadians didn't take that simple precaution, then
for all practical purposes they gave the data away.
--
Prediction is difficult, especially of the future. - (Niels Bohr)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
Date: Fri, 25 Aug 2000 22:17:39 GMT
In article <NCBp5.663$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Mike Andrews) wrote:
> Scripsit Mok-Kong Shen <[EMAIL PROTECTED]>:
>
> : If a security/intelligence agency is not careful enough
> : to examine whether the software used is safe, then, if
> : unfavourable things happen, these are well 'deserved'.
> : See also my follow-ups in the thread 'Serious PGP v5 &
> : v6 bug!'.
>
> It's worse than that! What was a computer that handled Top Secret
> data doing connected to _ANY_ sort of external network -- even
> the Public Switched Telephone Network? It makes no sense at all.
>
> Systems that handle any sort of classified data need to be
> completely isolated from any connection to any insecure network.
> That's Rule #1
>
> If the Canadians didn't take that simple precaution, then
> for all practical purposes they gave the data away.
Can we distinguish between stupid government and citizens please?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: Crypto Coprocessor on Javacard
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 25 Aug 2000 16:33:28 -0600
[EMAIL PROTECTED] don't know of any smart cards that have crypto coprocessors for DES
> >operations, just RSA, so that part of your question is unanswerable.
>
> GemPlus GPK4000 has DES and at least one mode of 3DES (2 keys, not three).
> And RSA up to 1024 bits. It's been around for at least three years.
> I don't remember the DES speed, other than "pretty slow".
Yes, it can do DES and 3DES, but they're implemented in software -- no
crypto coprocessor.
Shawn.
------------------------------
Subject: Re: Crypto Coprocessor on Javacard
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 25 Aug 2000 22:39:11 GMT
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> >I don't know of any smart cards that have crypto coprocessors for DES
> >operations, just RSA, so that part of your question is unanswerable.
>
> GemPlus GPK4000 has DES and at least one mode of 3DES (2 keys, not three).
> And RSA up to 1024 bits. It's been around for at least three years.
> I don't remember the DES speed, other than "pretty slow".
Yes, it can do DES and 3DES, but they're implemented in software -- no
crypto coprocessor.
Shawn.
------------------------------
Subject: Re: Crypto Coprocessor on Javacard
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 25 Aug 2000 22:39:18 GMT
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> >pbz[Rot 13] (Eric Murray) writes:
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> >I don't know of any smart cards that have crypto coprocessors for DES
> >operations, just RSA, so that part of your question is's been around for at least
>three years.
> I don't remember the DES speed, other than "pretty slow".
Yes, it can do DES and 3DES, but they're implemented in software -- no
crypto coprocessor.
Shawn.
------------------------------
Subject: Re: Crypto Coprocessor on Javacard
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 25 Aug 2000 22:39:33 GMT
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> >I don't know of any smart cards that have crypto coprocessors for DES
> >operations, just RSA, so that part of your question is unanswerable.
>
> GemPlus GPK4000 has DES and at least one mode of 3DES (2 keys, not three).
> And RSA up to 1024 bits. It unanswerable.
>
> GemPlus GPK4000 has DES and at least one mode of 3DES (2 keys, not three).
> And RSA up to 1024 bits. It3DES, but they're implemented in software -- no
crypto coprocessor.
Shawn.
------------------------------
Subject: Re: Crypto Coprocessor on Javacard
From: Shawn Willden <[EMAIL PROTECTED]>
Date: 25 Aug 2000 16:34:02 -0600
[EMAIL PROTECTED][Rot 13] (Eric Murray) writes:
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> >I don't know of any smart cards that have crypto coprocessors for DES
> >operations, just RSA, so that part of your question is unanswerable.
>
> GemPlus GPK4000 has DES and at least one mode of 3DES (2 keys, not three).
> And RSA up to 1024 bits. It's been around for at least three years.
> I don't remember the DES speed, other than "pretty slow".
Yes, it can do DES and 3DES, but they're implemented in software -- no
crypto coprocessor.
Shawn.
------------------------------
From: Michael Rubenstein <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Fri, 25 Aug 2000 18:50:33 -0400
On Fri, 25 Aug 2000 22:24:42 +0100, Richard Heathfield
<[EMAIL PROTECTED]> wrote:
>(I'm thinking of the
>rule that what we might call 'normal' characters must have a positive
>value - I can't find it in the C99 Standard but I'm reasonably sure it's
>there).
Your confidence is justified. 6.2.5 paragraph 3
------------------------------
From: S.R. Heller <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 16:01:08 -0700
Reply-To: [EMAIL PROTECTED]
On Fri, 25 Aug 2000 14:23:13 +0100, Phil Harrison <[EMAIL PROTECTED]>
wrote:
[ ... ]
>The help file says the following:
>
>--------------------------------------------------------
>Warn When Encrypting Keys to keys with an ADK
>
>Warns you if the key you are encrypting to is also encrypted to an
>Additional Decryption Key (ADK).
>--------------------------------------------------------
>
>This was certainly enough to cause this native English speaker to
>believe that I would get some kind of warning if the key I was
>encrypting to had an ADK. However my own tests seem to verify what Steve
>said. You don't get a warning even when this option is selected.
If I understand the correction offered via e-mail from someone at PGP, the
"warning" is the appearance of the ADK on the recipients dialog. The "Warn"
feature forces that warning to appear by forcing the dialog to appear in
plugins where it wouldn't otherwise be shown. I'm just guessing now, but I
think that in plugins the list of recipients is grabbed out of the To: field
in an e-mail client; with "Warn" switched on, you'll still be offered the
recipients dialog and thereby get a chance to see that an ADK has been
added. I don't think many people would deny that this could have been
presented a little better by the software or explained a little better by
the documentation.
>Admittedly the problem is perhaps not as bad as some people think, since
>you actually need to have the ADK on your keyring as well as the
>recipient's key. However, it does look as though this whole ADK feature
>was implemented in a bit of a sloppy way.
I personally have no beef with ADK in a business setting, but the bug shows
that if it isn't implemented carefully ADK can provide a means for what is
in effect ADK to be slipped in on any vulnerable key. I had to research this
subject a few months ago for some software of my own. It's a little
convoluted, but like PGP itself there is a conceptual hump that you have to
get over and then ... it ... sort of makes sense.
SH
------------------------------
From: S.R. Heller <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: "Warn when encrypting to keys with an ADK"
Date: Fri, 25 Aug 2000 16:13:37 -0700
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
On Fri, 25 Aug 2000 13:58:56 GMT, Ron B. <[EMAIL PROTECTED]> wrote:
>I followed through on your suggestion and verified that you are
>correct. The warn label seems to apply to the enforced AAR only.
>However, from the pgpwinusersguide.pdf documentation:
>
>• Warn when encrypting to an ADK. Use this checkbox to specify
>whether
>to issue a warning whenever an encrypt-to key has an associated
>Additional Decryption Key.
>
>Is this an error in the documentation or a deliberately misleading
>statement?
I'm sure this is only an ambiguous statement, trying to encapsulate a
complex process. If you are encrypting to a public key with
Additional Recipient Request (ADK) and you are using a plugin which
doesn't normally present the recipients dialog, selecting the "Warn"
option will force the recipients dialog to appear, thereby giving you
the chance to see that an ADK has been added to the recipients list.
That's the warning.
Steve H.
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
iQCVAwUBOab9nE/8MJkAFkZtAQFVtwP/ev6fVMt+XJUaDH8gY2c2jMB+ScI1kucq
EZ1s2HNHBiDAGo2Dn2bgnAD1BGYycOATU1kLoPLmausK/QvIpAifpMPPO9GvXsul
xb2kWP5nk4XIjs9qNMlrikC5jKwHnlYXVYn5t4wt3E4JtiyxVCCi0QHF/p8NMG+u
kHxSBAjXtp4=
=r2li
=====END PGP SIGNATURE=====
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Test on pseudorandom number generator.
Date: Fri, 25 Aug 2000 16:46:56 -0700
Cristiano <[EMAIL PROTECTED]> wrote in message
news:8o6bvq$orm$[EMAIL PROTECTED]...
<Snip tables and stuff>
<The differences in the table above are not detected by any statistical test
<used in my program (FIPS PUB 140-2, Diehard, Maurer's universal
<statistical test and others).
<Can anybody say me if my test is right? Why the statistical tests doesn't
<detect these differences?
Douglas A.Gwyn's answer sounds good to me But, I've been getting to know
diehard latetly and I'd like to take a few guesses about your results as
pertains to diehard.
Your 40 bit samples (assuming 5 bytes are 5*8 bits) are a weird multiple of
and bigger than the granularity of that used in the diehard tests.(Still
scratching my head about the bitstream test using 20 bit words).
Your data is showing a scarcity of collisions of 40 bit values when compared
to the reference set?
Just a guess but...
Wouldn't XORing one of your data sets with the reference set make a result
set with a scarceity of consecutive 0 values? I do not think that
performing a similar operation on any of the sercure PRNG's will show a
change in performance. But, It sounds like a fun thing to try!
I think I'll go do it.
Paul
------------------------------
From: [EMAIL PROTECTED] (Ben Ketcham)
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 16:44:53 -0700
In article <X8ip5.14845$[EMAIL PROTECTED]>,
mike burrell <[EMAIL PROTECTED]> wrote:
>In comp.lang.c Paul Schlyter <[EMAIL PROTECTED]> wrote:
>
>> On 64-bit machines, one alternative could be:
>>
>> char 8-bit
>> short short 16-bit
>
>short short? wtf is a short short? get it out of there whatever it is.
No, no, short shorts are your friends. Encourage their use wherever
possible (except where the even-better short skirt is available, of
course).
--ben
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math
Subject: Re: Sending Messages in Morse Code
Date: Sat, 26 Aug 2000 00:04:35 GMT
On Thu, 24 Aug 2000 17:35:53 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>You also might want to look at:
> http://www.joates.demon.co.uk/megs/N0HFF/c19a.htm
>which says Alfred Vail was the primary inventor of Morse code.
Yes, I saw that site. Of course, it was really Polybius who came up
with the idea in the first place...
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mark McIntyre <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Bytes, octets, chars, and characters
Date: Sat, 26 Aug 2000 01:12:09 +0100
Reply-To: [EMAIL PROTECTED]
On 25 Aug 2000 16:44:53 -0700, [EMAIL PROTECTED] (Ben
Ketcham) wrote:
>In article <X8ip5.14845$[EMAIL PROTECTED]>,
>mike burrell <[EMAIL PROTECTED]> wrote:
>>In comp.lang.c Paul Schlyter <[EMAIL PROTECTED]> wrote:
>>
>>> On 64-bit machines, one alternative could be:
>>>
>>> char 8-bit
>>> short short 16-bit
>>
>>short short? wtf is a short short? get it out of there whatever it is.
>
>No, no, short shorts are your friends. Encourage their use wherever
>possible (except where the even-better short skirt is available, of
>course).
keep taking the pills.
--
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
------------------------------
From: Eric Smith <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c,alt.folklore.computers
Subject: Re: Bytes, octets, chars, and characters
Date: 25 Aug 2000 17:22:31 -0700
Joona I Palaste <[EMAIL PROTECTED]> writes:
> Processor trivia: The 6510 microprocessor includes the instruction
> JAM (code 0x02), which will completely hang (ie. jam) the computer.
> To be able to proceed, you must do a power-cycle. What the heck is the
> use of this instruction?
Reset terminates that sequence as well. AFAIK, that is not an officially
documented instruction, and JAM is not an official mnemonic.
The 6502, on which the 6510 is based, will do the same thing for any of
thirteen of the undefined opcodes with the LSB hex digit of 2. They
simply start the address bus counting up. One such opcode was likely
designed in for manufacturing test purposes. The other twelve are just
artifacts of incomplete decoding.
The Motorola 6800/6802/6808 and 6809 also have at least one undefined
opcode that does this. On the 6801/6803/68120, Motorola documented that
two opcodes do it, but did not give mnemonics for them.
Colloquially, such opcodes are often referred to as "Halt and Catch Fire",
or HCF. There is an urban legend that such opcodes will result in
processor damage, but this is false. They don't stress the processor
any more than normal execution, and in fact probably less.
Eric
------------------------------
From: [EMAIL PROTECTED]
Subject: PRNG Test Theory
Date: Sat, 26 Aug 2000 00:16:23 GMT
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.
If you think about a order-0 predictor, we can simply output the next
bit that is statistically expected ... i.e in the stream 0011011 the
next bit should be '0' to make the balance even.
However, starting with no previous state the output will be alternating
0's and 1's.
Howeverx2, In conjunction with the plethora of other tests the next bit
should be able to be made more random. For example, the next bit from
the serial correlation test of 010101 will be '1' since 1 is serially
correlated with 0.
Interesting theory?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Big Boy Barry" <[EMAIL PROTECTED]>
Subject: Best way!
Date: Sat, 26 Aug 2000 00:54:27 GMT
Hello,
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.
------------------------------
From: Daniel Newby <[EMAIL PROTECTED]>
Subject: Re: An interesting cryptographic problem
Date: Fri, 25 Aug 2000 19:58:22 -0500
[EMAIL PROTECTED] wrote:
>
> Modern line-of-business systems typically rely on a relational database
> to store information. A user supplies a set of credentials
> (login,password) to the system and is then connected to the RDBMS.
>
> A naive implementation of such a system (and unfortunately, this is a
> common implementation) simply forwards the user's credentials to the
> RDBMS and if the RDBMS validates them, the user is directly connected.
>
> The problem with such an implementation is that the user must often be
> given quite broad rights to database tables in order for the line-of-
> business application to function correctly. Although most modern RDBMS
> products have excellent security systems, enforcing table-level
> security is tedious and in many cases causes the application code to
> malfunction, because it was written with the assumption that full
> permissions to the base tables are available.
Let me succinctly state the problem: users are granted RDBMS access
permissions they should not have, in order that flawed applications may
run.
There it is. No amount of talking can cover up that ugly fact. The
user can destroy and forge data, but they should not be able to.
You go on to say what the consequences are:
> Because the user can easily access the database using third-party query
> and reporting tools, any application-level security is easily bypassed.
> This leads to serious security weaknesses and potential audit
> nightmares.
You use the phrases "serious security weaknesses" and "potentional audit
nightmares". You didn't say, but I'm assuming the database contains
corporate financial information (or inventory and sales data, which is
about the same). Presumably the sort of information that gets used
in SEC filings, and quarterly reports to investors. The sort of
information that, if it is falsified, will lead to fines, bad publicity,
or even prison sentences. Not to mention the straightforward risk of
bankruptcy if somebody spends money that isn't there.
In a later posting, you said:
> DES is more than sufficiently secure for this
> application, which is not 'mission-critical'. DES in CFB mode has the
> advantage that successive encryptions of the same plaintext produce
> different encrypted text. This makes dictionary attacks much less easy.
How do you go from "audit nightmare" to "not mission-critical"?!
"Mission-critical" doesn't mean the world will end if it fails, it just
means the organization's mission is at stake. Financial and operating
data normally *is* mission critical, especially if it is used as a
basis for government financial filings. Maybe it's time to go read that
mission statement? ;-)
You need to do some threat modeling. If the threat is accidents
committed by benevolent employees, then just about any solution will
work. If the threat is deliberate fraud by motivated opponents, and
there are large financial and legal stakes, then half-measures are
worthless: someone will eventually do the necessary work to break
them.
In fact, a half-measure will be worse than no security. Few people
are knowledgable about security. In their ignorance, many people will
therefore rely on the half-assed security as if it were real security.
When the inevitable violation occurs, they will be shocked and angry.
The recriminations and lawyers will fly; your product will be blamed
both for having poor security and for being violated. If the data
is as important as I suspect it is, careers and businesses could be
destroyed.
Unless you implement complete end-to-end transaction security, your
only security is illusions. Worse, the amount of effort needed to
lift the veil of illusion is unknown and probably very small. Breaking
your proposed security DLL would be trivial -- there are people who
do that sort of thing for a hobby. Not to mention the fact that
any network sniffer could just grab the encrypted authentication data
{u',p'} right off the wire -- no programming ability necessary.
If you think the stakes are low enough, feel free to use illusory
security. But if the stakes are high, you're just sticking your
head in the sand.
-- Daniel A. Newby
(Speaking for myself, not my employer.)
------------------------------
** 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
******************************
