Cryptography-Digest Digest #823, Volume #8 Fri, 1 Jan 99 18:13:04 EST
Contents:
OTP/FTP/MTP Question (Earl Pottinger)
Re: FAQ: as up to date as it should be? (Entschuldigung)
Re: Open source Crypto algorithms in Java (Mr. Tines)
Re: Security through obscurity in the smartcard world (Gurripato (x=nospam))
Re: GSM Hack [Was Security through obscurity in the smartcard world] (Gurripato
(x=nospam))
Re: FAQ: as up to date as it should be? (R. Knauer)
Re: OTP/FTP/MTP Question (R. Knauer)
Re: A review of Scramdisk (Aman)
Does someone have any information to Enigma 98 - Security? ("LP")
Re: FAQ: as up to date as it should be? (George Barwood)
Re: Common Modulus Attack on RSA (Ted Kaliszewski)
Re: coNP=NP Made Easier? (rosi)
PGP Keys on Smartcard ("fred")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Earl Pottinger)
Subject: OTP/FTP/MTP Question
Date: 1 Jan 99 17:07:09 GMT
Hello,
I don't know what the proper terms to use to do a DejaNews search,
so if this has been discussed before please could you supply a few search
terms for me.
If a OTP is many times larger than the total messages sent, then as long
as the communicating parties stay in sync then the messages should be
unbreakable, I think.
Where is the source of such a large OTP to come from. It seems that a
random number generator based of shifting a seed number with EOR feedbacks
should do this fine. However, I was think of a hardware/software design
where the starting seed would be very large IE 20^20 to 2^28, a lagre seed
could be used but this is small enought to fit on a floppy for
transportation.
If sync is lost because of some one trying hack the system then it can be
restore by sending a clear text message to restart a X cycles from the
first seed configuration.
Questions;
Multiple restarts are a weak point, can the first restart be
used to transmit a new seed safely?
Testing for small arrays (4-8 bits) I found if I knew the clear
text I could figure out the seed and feedback using long messages.
However I could not do that if the message shorter than the repeat pattern
of the RNG. It was however still hard to break by hand.
Must the lenght of the seed always be longer than any message
sent? Or will a 2^20 seed hard to break even if used to send a 2^28
lenght message?
Are there simpler ways to break the RNG seed that I don't know
about? I expect a yes to that question.
Earl Colby Pottinger
---------------------------------------------------------------------
: Internet Direct. Have you heard about our :
: (416)233-2999, 1000 lines Do-It-Yourself Webserver? :
: T3 bandwidth, 9600-33,600bps+ISDN http://web.idirect.com :
---------------------------------------------------------------------
------------------------------
From: Entschuldigung <[EMAIL PROTECTED]>
Subject: Re: FAQ: as up to date as it should be?
Date: Fri, 01 Jan 1999 08:26:06 -1000
Joel Noble wrote:
>
> Hi, all.
>
> I was just taking a peek at the FAQ (it'd been a couple years), and it seems
> that it hasn't been
> updated since 1994.
>
> I'm no expert in this area, but I was wondering if folks think it needs
> anything new. Are there other genuine frequently-asked-questions we want in
> there? Is any of the existing information due for updating?
>
> ...or was I just not looking in the right place for the current version? :)
>
> Thanks,
>
> Joel Noble
> [EMAIL PROTECTED]
I do not know where you get your FAQ, but I use:
http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq/part01/faq.html
Here is an excerpt from the FAQ of January 11, 1994:
"Cryptography FAQ (01/10: Overview)
Archive-name: cryptography-faq/part01
Version: 1.0
Last-modified: 94/01/11
This is the first of ten parts of the sci.crypt FAQ. The parts are
mostly independent, but you should read this part before the rest. We
don't have the time to send out missing parts by mail, so don't ask.
Notes such as ``[KAH67]'' refer to the reference list in the last part.
Disclaimer: This document is the product of the Crypt Cabal, a secret
society which serves the National Secu---uh, no. Seriously, we're the
good guys, and we've done what we can to ensure the completeness and
accuracy of this document, but in a field of military and commercial
importance like cryptography you have to expect that some people and
organizations consider their interests more important than open
scientific discussion. Trust only what you can verify firsthand.
And don't sue us.
Many people have contributed to this FAQ. In alphabetical order:
Eric Bach, Steve Bellovin, Dan Bernstein, Nelson Bolyard, Carl Ellison,
Jim Gillogly, Mike Gleason, Doug Gwyn, Luke O'Connor, Tony Patti,
William Setzer. We apologize for any omissions.
If you have suggestions, comments, or criticism, please let the current
editors know by sending e-mail to [EMAIL PROTECTED]"
In the opinion of this anonymous participant, it does not need any
changes. It is useful for basic information. Advanced informations is
already available from other sources. RTFB!
------------------------------
From: Mr. Tines <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.java.programmer,comp.lang.java.security
Subject: Re: Open source Crypto algorithms in Java
Date: 01 Jan 1999 17:08 +0000
###
On Fri, 01 Jan 1999 11:21:43 GMT, in <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (KloroX) wrote.....
> On 29 Dec 1998 15:50 +0000, Mr. Tines <[EMAIL PROTECTED]>
> wrote:
>
> >A quick follow-up to self - I've split the pure algorithm
> >code out from the application archive; to just access the
> >various algorithms (3Way, Blowfish, CAST5, DES, tripleDES,
> >Square, SAFER, TEA, MD5 SHA0, SHA1, HAVAL, RIPEM160) these
> >now stand alone (with the appropriate interface definitions)
> >at
> >
> >http://www.windsong.demon.co.uk/crypt.zip
>
> The link does not work...
Does it work now??
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED] PGP key on page
### end pegwit v8 signed text
851838b72bc65f3af34bf3a9a7b3fab6f94e1c869ef49f53cf1e11154447
f0c01b7e14ba7165e02bf2729de87096f08b600272c9954c2bf85e43dacb
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: Security through obscurity in the smartcard world
Date: Fri, 01 Jan 1999 16:42:51 GMT
On Wed, 30 Dec 1998 09:22:00 -1000, liminal <[EMAIL PROTECTED]> wrote:
>> Gary Howland <[EMAIL PROTECTED]>
>
>People who care about the privacy of their own files and messages should
>write their own obsure software. They should not try to sell it to the
>public. If hundreds of people did this, they would be almost safe from
>professional cryptanalysis, since that task is so difficult and there are
>far fewer cryptanalysts than programmers. People who try to sell obscure
>crypto create a laughing stock. The comedy warehouse is half full of
>laughingstock, there is room for much more.
I completely disagree. Since most people are not professional
cryptographers, it is too easy (and too often) to write an "unbreakable"
cipher that comes down at the first attack. Instead of having people
use a strong algorithm and a strong implementation of it, you would see
a million easy-to-break algorithms.
>Ciphertext files can be obscured so they look like either random data or
>innocent data.
This would make for a good operational description of
"encryption". Now for the hard part: how to make them easy to
cryptanalyze. Random-looking is good, but not enough.
>Store the floppy in a heavy safe, preferably in a bunker that is
>radiation-hardened using standard methods which typically
>require that the bunker be lined with lead or boron at least 4mm thick,
>encased in a vacuum envelope composed of
>magnesium that is separated from, and magnetically suspended by, a
>gadolinium-nickel alloy cable that is at least 12
>meters long over an earthen pit containing a shallow pool of fuming red
>nitric acid so that if these precautions are taken,
>and the Big One does not hit, then an insurance policy may become
>available for a nominal fee which would absolutely
>reimburse you for the cost of the floppy disk in case it is stolen while
>being transported by trusted courier to the person
>with whom you wanted to share the secret key. Alternatively, you could
>use public-key cryptography to send the secret
>key to your friend, in which case, the potential offer of an insurance
>policy would be null and void.
Short of leaving a message for future generations or alien
civilizations 100 years from now, what would it be good for? I doublt
it would make a good marker!
------------------------------
From: [EMAIL PROTECTED] (Gurripato (x=nospam))
Subject: Re: GSM Hack [Was Security through obscurity in the smartcard world]
Date: Fri, 01 Jan 1999 16:58:33 GMT
On Thu, 31 Dec 1998 15:55:14 GMT, [EMAIL PROTECTED] (Gary Howland) wrote:
>On 29 Dec 1998 22:20:07 GMT, [EMAIL PROTECTED] (Ian Goldberg)
>wrote:
>
>>In article <76b57t$[EMAIL PROTECTED]>, Gary Howland <[EMAIL PROTECTED]> wrote:
>>>Admittedly, in the case of the GSM hack, early peer review of the
>>>system might have resulted in SIM cards that cannot be cloned at
>>>the present time, since they (the GSM designers) might have used
>>>a better algorithm due to the peer review. But who's to say that
>>>the pre-launch publication of the algorithms would have spotted
>>>it,
>>
>>Well, it took Dave and me about 2 hours (over an Indian buffet lunch at
>>Rajah's in Berkeley) to break it; it stands to reason that others could
>>have done the same...
>
> I'm not disputing this - I'm just saying _if_ - after all, systems in
>widespread use get more scrutiny than those that aren't even out yet.
Obviusly, it is easier to see something if it is right in front
of you. The problem is, obscurity-based systems rely on nobody finding
out the algorithm; on the other hand, in-the-open systems have to be
more secure, if only because juse about anybody will be able to see it
and give it a try. Hence, the need for more strength.
>
>One claim I have heard is that a SIM can be stolen, and copied onto
>thousands of cards. Fine, we now have a problem. So what are the
>service providers going to do? They'll just disable all *phones* that
>use the stolen SIM.
And see your business plummet down as soon as the general public
discovers that a) your system is susceptible to cloning and b) that if
it does, all the service provider can do is shut all clones down,
including the legal one.
>Once this happens, and it becomes public
>knowledge that the use of a stolen SIM can effectively break your
>mobile phone, then the market for these dodgy black market cards will
>disappear, and so will the security problem.
Not if the phone is stolen, the SIM copied (or even cloned) and
given back to the owner, perhaps without he/she knowing it. Or if new
techniques allow for the cloning witohut physical possesion of the SIM
card (via multiple queries, for example).
It is like saying: well, as soon as your Visa is stolen, you
report it and it will be cancelled, therefore the burglars will gain
nothing. And yet, Visas (and other credit cards) are stolen every day.
>But as for the current time, sure, the odd hacker will be able to get
>free calls, but this isn't a concern of the service providers,
It isnīt? I mean, I can have my SIM cloned and that it is?
Well, somebody will have to pay for the calls, either me or the
provicer; in either case, the service provider has a problem, be it on
their notebooks or in court, facing my lawyer.
>However, if SIMs could be created from the data snatched from the
>airwaves, rather than being stolen from hire cars etc., then, yes, we
>have a serious security problem with the system. But this is not the
>case, and there are currently no security concerns in this area.
According to the Smartcard Developers Association, "no practical
over-the-air attack is known yet but that should be not ruled out" (from
an April 1998 press release, available at
http://www.scard.org/press/19980413-01/) If "concerns" means to you
"letīs not worry until it really happens" fine, but otherwise I think it
is just a matter of time.
>Some people might claim that these extra security features should
>already be in place - but why should a company waste time and money on
>fixing something that is not yet a problem (as long as it knows it can
>do so in the future)?
For the same reasons our cars carry a spare tire even when
travelling on good roads: no trouble ahead, but letīs be prepared in
case there is any.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: FAQ: as up to date as it should be?
Date: Fri, 01 Jan 1999 19:28:30 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 01 Jan 1999 08:26:06 -1000, Entschuldigung
<[EMAIL PROTECTED]> wrote:
>I do not know where you get your FAQ, but I use:
>
>http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq/part01/faq.html
Where is there a good FAQ on ECC?
Bob Knauer
"Who can protest an injustice but does not is an accomplice in the act."
--The Talmud
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: OTP/FTP/MTP Question
Date: Fri, 01 Jan 1999 19:31:48 GMT
Reply-To: [EMAIL PROTECTED]
On 1 Jan 99 17:07:09 GMT, [EMAIL PROTECTED] (Earl Pottinger) wrote:
These questions, and a whole lot more, are covered in Bruce Schneier's
book "Applied Cryptography". There are other fine books but that
should be your first read.
Bob Knauer
>Hello,
> I don't know what the proper terms to use to do a DejaNews search,
>so if this has been discussed before please could you supply a few search
>terms for me.
>
>If a OTP is many times larger than the total messages sent, then as long
>as the communicating parties stay in sync then the messages should be
>unbreakable, I think.
>
>Where is the source of such a large OTP to come from. It seems that a
>random number generator based of shifting a seed number with EOR feedbacks
>should do this fine. However, I was think of a hardware/software design
>where the starting seed would be very large IE 20^20 to 2^28, a lagre seed
>could be used but this is small enought to fit on a floppy for
>transportation.
>
>If sync is lost because of some one trying hack the system then it can be
>restore by sending a clear text message to restart a X cycles from the
>first seed configuration.
>
>Questions;
> Multiple restarts are a weak point, can the first restart be
>used to transmit a new seed safely?
>
> Testing for small arrays (4-8 bits) I found if I knew the clear
>text I could figure out the seed and feedback using long messages.
>However I could not do that if the message shorter than the repeat pattern
>of the RNG. It was however still hard to break by hand.
> Must the lenght of the seed always be longer than any message
>sent? Or will a 2^20 seed hard to break even if used to send a 2^28
>lenght message?
>
> Are there simpler ways to break the RNG seed that I don't know
>about? I expect a yes to that question.
>
> Earl Colby Pottinger
> ---------------------------------------------------------------------
> : Internet Direct. Have you heard about our :
> : (416)233-2999, 1000 lines Do-It-Yourself Webserver? :
> : T3 bandwidth, 9600-33,600bps+ISDN http://web.idirect.com :
> ---------------------------------------------------------------------
"Who can protest an injustice but does not is an accomplice in the act."
--The Talmud
------------------------------
From: [EMAIL PROTECTED] (Aman)
Crossposted-To: alt.security.pgp
Subject: Re: A review of Scramdisk
Date: Fri, 01 Jan 1999 20:04:17 GMT
On 27 Dec 1998 08:42:01 -0600, [EMAIL PROTECTED] (Sh) wrote:
>On Fri, 24 Jul 1998 21:26:48 GMT, [EMAIL PROTECTED] (Lincoln Yeoh)
>wrote:
>
>>First, let me thank you again
This has been resent in error. From July!
Don't ask me what happened, but sorry folks!
Regards,
Aman.
------------------------------
From: "LP" <[EMAIL PROTECTED]>
Subject: Does someone have any information to Enigma 98 - Security?
Date: Fri, 1 Jan 1999 21:19:22 +0100
------------------------------
From: [EMAIL PROTECTED] (George Barwood)
Subject: Re: FAQ: as up to date as it should be?
Date: Fri, 01 Jan 1999 22:04:29 GMT
On Fri, 01 Jan 1999 19:28:30 GMT, [EMAIL PROTECTED] (R. Knauer)
wrote:
>On Fri, 01 Jan 1999 08:26:06 -1000, Entschuldigung
><[EMAIL PROTECTED]> wrote:
>
>>I do not know where you get your FAQ, but I use:
>>
>>http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq/part01/faq.html
>
>Where is there a good FAQ on ECC?
Try http://ds.dial.pipex.com/george.barwood/ec_faq.htm
George (although I wouldn't like to claim it is good)
------------------------------
From: Ted Kaliszewski <[EMAIL PROTECTED]>
Subject: Re: Common Modulus Attack on RSA
Date: Fri, 1 Jan 99 17:21:03 -0500
If you really want to get a correct answer to your question, refer to an
article by John M. DeLaurentis in Cryptologia (July 1984). The problem is
elegantly solved and that implies that knowing the set (e,d,n) the factoring
of n is quite simple.
------------------------------
From: rosi <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: coNP=NP Made Easier?
Date: Fri, 01 Jan 1999 11:42:17 -0800
Dear Ilias,
I see that you see that M behaving as described in 26 is NOT
fine.
But you said there exists such a mechanism, NDTM to be exact,
that behaves as described in 26 (and you do not need to show its
construction and it simply exists). I seem to have the impression
from your that the only valid type of NDTM are those behaving as
described in 26 (as you would not take anything but your K).
Now things are simpler. As there can only be NDTM behaving as
described in 26, the answer to my FIRST crucial question should be
NO. Because obviously, your K (a representative of those NDTM's
behaving as described in 26) can halt with things other than YES#
on its output tape, your K is not the mechanism I am asking for.
And according to you, unless I am wrong, that the only halting and
output behaviour of an NDTM is as described in 26, so no NDTM can
be the one I am asking for. So the answer should be simply NO. I
do not understand why always such fuss. Just as for the simple
answer to the simple question about a mechanism that solves SS
in finite time, I can not understand why the fuss about NDTM and
DTM. If there exists one (DTM or NDTM), just say YES. A primary
school kid would do so.
We are slowing down. Let me speed up by asking the crucial
question once more (and this time in full to save us one round of
posts):
41. Does there exist a mechanism MM (ANY mechanism) that,
when S, a finite set of integers, i', a subset sum of S,
and n the size of the input/problem) are given as input,
_ALWAYS_ HALTS within a polynomial bound (or in other
words: whose complexity is bounded by some polynomial
function f(n) where n is the input/problem size) and
_ALWAYS_ ANSWERS POSITIVELY (or our version to be specific:
prints YES# on its output tape on halt); AND that, when S,
a finite set of integers, i", an integer that is NOT a
subset sum of S, (and n the size of the input/problem) are
given as input, _NEVER_ prints YES# on its output tape?
42. (If you do not feel comfortable with 41, try this one)
Do you assume the existence or non-existence of a mechanism
MM (ANY mechanism) that, when S, a finite set of integers,
i', a subset sum of S, and n the size of the input/problem)
are given as input, _ALWAYS_ HALTS within a polynomial bound
(or in other words: whose complexity is bounded by some
polynomial function f(n) where n is the input/problem size)
and _ALWAYS_ ANSWERS POSITIVELY (or our version to be
specific: prints YES# on its output tape on halt); AND that,
when S, a finite set of integers, i", an integer that is
NOT a subset sum of S, (and n the size of the input/problem)
are given as input, _NEVER_ prints YES# on its output tape?
Repetition and details do not bore everybody every time. So
here we go again:
If MM(S, i', n) EVER prints anything other than YES# at halt,
it is NOT the mechanism I am asking for.
*** IMPORTANT: it seems that your K is obviously ruled out,
*** and you should have realized this long, long ago. A high-
*** school kid would. So please do not bring it back to create
*** further headache. I am asking for one that ALWAYS prints
*** YES# at halt AND halts within polynomial bound. If you can
*** not think of one or can prove that in this whole wide
*** world there is none, you can simply say "NO" to the question.
*** If you are right, you will be right. The world is watching us).
If MM(S, i', n) EVER prints YES# only after exp time, it is
NOT the mechanism I am asking for. (This means if there is ever an
instance with the tuple <S, i', n> that results in MM printing YES#
only after exp time, it is NOT the mechanism I am asking for.)
If ALWAYS MM(S, i', n) < f(n) and prints YES# at halt, and
ALWAYS MM(S, i", n) < g(n) for some polynomial g and NEVER prints
YES#, it _IS_ the mechanism I am asking for (am not implying in
any way that it exists).
If ALWAYS MM(S, i', n) < f(n) and prints YES# at halt, and
MM(S, i", n) NEVER halts and NEVER prints YES#, it _IS_ the
mechanism I am asking for.
If MM(S, i", n) EVER prints YES#, it is NOT the mechanism I
am asking for.
I repeat, there is no multiple run issue. This mechanism should,
if one exists at all, _ALWAYS_ halt within polynomial bound and
print YES# at halt after it is started (or the "START" button is
pushed).
As far as I can see, there are only three meaningful answers to
41 (or 42):
YES, THERE IS (or I ASSUME THE EXISTENCE)
NO, THERE IS NONE (or I ASSUME THE NON-EXISTENCE)
I DO NOT KNOW
Please provide straight and clear answers. Please do not evade.
When answer other than "I DO NOT KNOW" to 41 (or 42) is provided,
I will evaluate the answer and bring this boring topic to an end
(hopefully).
As to "I DO NOT KNOW", I can close the chapter right here.
You do not know what you have been talking about. You have
wasted people's time and bandwidth.
If anybody has an answer other than "I DO NOT KNOW" to 41 (or 42),
please let me know so that my breath is not totally wasted.
Thank you very much.
--- (My Signature)
P.S.
Ilias:
With your kind help (through the clinging onto 26 and your K),
my definitions (NHPSM and output equivalence) and the assumption
are not needed in demonstrating my point. Thank you. :)
Bryan, Rune, Vladimir:
If you see pupil to pupil with Ilias on the prvious questions,
you may try to answer this one (41 or 42) as well. Then I would
not need to pursue the thread with you any more.
For Bryan, if according to your understanding, the NDTM
you quoted behaves (in terms of halting and output) as described
in 26, please let me know. That case, your questions, I believe,
can also be answered.
There is a very important point, though even high-school kids
can see. I think it better to make it as explicit and clear as
possible so that I do not give the impression that I am trying
to trick anybody (in slightly abstract form):
I say: (It is true that) if A (is true) then B (is true)
I do not say: A (is true)
I do not say: B (is true)
I only establish the derivation from A to B
I am not concerned with whether A is actually true (for
the truth value of 'if A then B')
------------------------------
From: "fred" <[EMAIL PROTECTED]>
Subject: PGP Keys on Smartcard
Date: Fri, 01 Jan 1999 17:23:23 -0500
Hi there.
I'm a PGP User on Windows NT and would prefer to
keep my secret keys on a smartcard which would always
physically reside with me.
Does such a product exist? I would ideally like to think that
my secret keys always remained on the card and that signing
and digest creationn occured on the card. That way my keys
couldn't be snaffled away by a miscreant program on my NT
workstation.
Has anyone done this or am I about to make my fortune?
Thanks in advance,
Gavin
------------------------------
** 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
******************************
