Cryptography-Digest Digest #202, Volume #11 Fri, 25 Feb 00 20:13:02 EST
Contents:
looking for light duty multi-platform encryption (James Ferguson)
Re: Cryption Techniques and others (drickel)
Re: Cryption Techniques and others (JPeschel)
Re: CRC-16 Reverse Algorithm ? (John Savard)
Re: Nanotechnology ([EMAIL PROTECTED])
Re: Question about OTPs (Bryan Olson)
Re: FIRST TIME! ("Jean Pierre")
Re: Digital Tontines [Was: FIRST TIME!] ("Jean Pierre")
Re: CRC-16 Reverse Algorithm ? (Doug Stell)
Are "self-shredding" files possible? ("Thomas Moore")
PDF problems (David Hopwood)
Re: Are "self-shredding" files possible? (Walter Roberson)
235 and counting ("Chuck Davis")
----------------------------------------------------------------------------
From: James Ferguson <[EMAIL PROTECTED]>
Subject: looking for light duty multi-platform encryption
Date: 25 Feb 2000 13:54:11 -0800
Searching for libraries...:
I'm looking for encryption libraries for use on multiple platforms
(Unix C++, MS VB, Java). I am looking for freely available libraries,
that can be used within commercial applications (i.e not GPL).
The strength of the encryption isn't vital - it just shouldn't be
trivial to break. E.g DES or something might be fine.
I've been searching around, but flailing in information overload, so
I'm hoping knowledgeable people can swiftly point me at something...
I'm not sure what encryption scheme to go with, and then where I could
get libraries for all these platforms...
Thanks in advance.
James.
------------------------------
Subject: Re: Cryption Techniques and others
From: drickel <[EMAIL PROTECTED]>
Date: Fri, 25 Feb 2000 14:12:16 -0800
In article <895ppk$duj$[EMAIL PROTECTED]>, "Osah"
<[EMAIL PROTECTED]> wrote:
>I'm new to this sort of thing so please forgive me for what i'm
about to
>ask.
>
>I tried to encrypt a file by XORing it with a string of integers
(6bytes in
>length), i can decrypt it using the same integer string, but i
want to know
>how to break it without using these integer strings (Any hint,
algorithm
>description or code in C/C++ would help a lot).
>
>Also, where can i get more information on crypting algorithms or
source
>code. I would like to learn more about it and how to implement
them......
>:-)
>
>Thanks....
>Cable_TXG
Oops, i misread it. You have 6 bytes of integers that you XORd
your file with? Is your file that short, or do you reuse the
integers every 6 bytes? The encryption should be trivial to
break if the source was english text (take every 6'th byte, do
frequency analysis to determine the most common letters, etc.).
I'd originally misread it as you xoring your file with 6 Mb of
random integers. In that case, the attack would be trying to
figure out how you generated your 6 Mb of integers (the rand()
function isn't very good as a source of cryptographically secure
numbers).
Bruce Schneier's book, Applied Cryptography, provides source
code and explanations, and is pretty widely available. The
Handbook of Applied Cryptography is available on the net; it
seems a bit more rigorous. There are other books
out there, but those would be a good start.
david rickel
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Cryption Techniques and others
Date: 25 Feb 2000 22:29:39 GMT
>drickel [EMAIL PROTECTED] writes:
>You have 6 bytes of integers that you XORd
>your file with? Is your file that short, or do you reuse the
>integers every 6 bytes? The encryption should be trivial to
>break if the source was english text (take every 6'th byte, do
>frequency analysis to determine the most common letters, etc.).
If Osah is re-using his six bytes, he has created a poly-alphabetic
substitution cipher that uses XOR for the substitution.
Usually, you need to determine the length of the key,
(but he already knows that) and then do frequency analysis
of each of the alphabets. I think his alphabet is from
0-255h instead of the classical 26 letters. If the alphabet
is 256, then the space character will likely be the most
frequent.
This sort of cipher is easy to break, and, as I said earlier
in this thread, Vcrack will break it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Fri, 25 Feb 2000 15:56:10 GMT
"Liu, Qingzhu [CAR:CF36:EXCH]" <[EMAIL PROTECTED]> wrote, in
part:
>I try to implement an algorithm for crc-16 reverse
>(Poly: 1 + x + x^14 + x^16) in PIC17c756 assembly code.
>My questions are:
>1. What does the "Reverse' mean ?
It isn't 1 + x^2 + x^15 + x^16, the polynomial turned around
'backwards'.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Nanotechnology
Date: Fri, 25 Feb 2000 22:57:22 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Recently I read a few papers on nanotechnology (a short English
> one is in IEEE Computer, Jan 00). It is interesting to note to
> what surprising extent the predictions of Feynman of 1959 have
> become true. One historical fact mentioned in a paper I read is
> that a paragraph Feynman's 1959 lecture, consisting of 115 words,
> was later put onto an area that is one thousandth of the size of
> the head of a needle. It is reasonable to assume that this
> lithographic technique has further advanced in the meantime.
>
> It may be of interest to note that in this specific area of
> nanotechnology, namely lithography, the technique is not
> unprecedented. Kahn's book (p.525-6) mentions the microdot,
> which was employed by German agents in WWII.
>
> In previous discussions of this group on one-time pad, I remember
> that one of the disadvantages being stressed is the inconvenience
> of transport, requiring under reasonable operating conditions
> a high number of CDs to store the large volume of bits of the OTP
> needed. However, using nanotechnology, it seems that the problem
> can be practically solved, though the cost involved probably is
> a barrier for most applications that potentially could utilize
> (good though non-ideal) OTPs.
>
Recent nano-CD technology already beats the capacity of regular CDs by
more than 800x. Only a few researchers have access to this but in the
future it might be produced at a reasonable cost.
> Does anyone happen to have informations concerning current
> applications of nanotechnology to cryptology? Thanks.
>
There are proposals for building or self assembling quantum computers
from nanosystems which might eventually be involved in cryptoanalysis.
> M. K. Shen
> ----------------------------
> http://home.t-online.de/home/mok-kong.shen
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Fri, 25 Feb 2000 23:05:21 GMT
[EMAIL PROTECTED] wrote:
> Bryan Olson wrote:
> : Hmmm, I guess I'm still not clear on what you meant. If you
> : were limiting "attack" to recovery of information, then
> : specifying ciphertext-only is wrong. [...]
>
> This time *I* am not sure what *you* mean.
I think the one sentence you snipped may be significant
here:
If you were including forgery, then the claim of
best possible resistance is false.
> An "ideal" OTP does resist cyphertext-only attacks
> about as well as it's possible to do.
Not attacks directed at authenticity. The chance of a
forgery that is valid message is a property of the message
space and outside the control of the OTP. If a forgery is
not a valid message, the OTP decryption process will not
detect it; instead it passes along garbage as if it were
plaintext
Good authentication systems detect and reject forgeries.
They can bring the chance of a successful forgery, whether a
meaningful message or not, arbitrarily close to zero
regardless of plaintext language.
> The structure resists other types of attacks to
> varying degrees. I did not mean to make any implied
> statement concerning other types of attacks.
We can classify attacks into "types" in more than one way.
In the case of the OTP, the significant distinction is
between attacks on privacy where the OTP provides "Perfect
Secrecy", and attacks on authentication, which the OTP does
not address. The distinction of attack type based on
attacker resource (known plaintext versus ciphertext only)
is relatively unimportant.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Jean Pierre" <[EMAIL PROTECTED]>
Subject: Re: FIRST TIME!
Date: Sat, 26 Feb 2000 10:20:39 +1100
Reply-To: "Jean Pierre" <[EMAIL PROTECTED]>
Thank you very much.
I visited your web site, and it was exactly what I was looking for.
Much obliged,
Jean-Pierre.-
>The square card you mentioned is called a turning grille. It is
: >treated in old litteratures on cryptology.
:
: And also on my web site at
:
: http://home.ecn.ab.ca/~jsavard/pp0102.htm
------------------------------
From: "Jean Pierre" <[EMAIL PROTECTED]>
Subject: Re: Digital Tontines [Was: FIRST TIME!]
Date: Sat, 26 Feb 2000 10:32:41 +1100
Reply-To: "Jean Pierre" <[EMAIL PROTECTED]>
M.K.SHEN, HEMRICK and SAVARD, thank you so much for all your kind and very
useful suggestions.
Jean-Pierre.-
------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: CRC-16 Reverse Algorithm ?
Date: Fri, 25 Feb 2000 23:34:15 GMT
On Fri, 25 Feb 2000 21:33:19 GMT, Anne & Lynn Wheeler
<[EMAIL PROTECTED]> wrote:
>
>one of the interesting things in CRC16 chips in the '70s where
>computer boxes using it for bit error detection and RF modem boxes
>using the same chip for eliminating runs of zeros. There was strange
>situation in some <college campus> RF/broadband systems which were
>getting undected transmission errors because of unfortunate
>interaction of using the same CRC16 recursively.
CRCs that are initialized to all zeros (CRC-16 is one of these) can
not detect the addition or deletion of leading zeros. Likewise, CRCs
that are initialized to all ones can not not detect the addition or
deletion of leading ones. That's why some CRCs initialize to some
known, fixed value that is neither all ones nor all zeros.
doug
------------------------------
From: "Thomas Moore" <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,alt.security.scramdisk,comp.security.misc,comp.security.pgp.discuss
Subject: Are "self-shredding" files possible?
Date: Fri, 25 Feb 2000 23:56:39 GMT
Does anyone know if it's possible to make a file "self-shredding?" I'm
thinking of something along the lines of PGP's self-decrypting file type.
I'm a regular on the groups that this question is posted to and have never
read about this topic.
I imagine being able to add or tag the "self-shredder" to a file, then
letting the user (this could be password protected or not) shred it after
any number of uses, or maybe after just one use. Files could also self-shred
after a certain time period - run them after such and such date and they
would just shred.
Maybe this idea just isn't possible. I'm not a programmer so I really don't
know. Please reply if you have any feedback.
------------------------------
Date: Fri, 25 Feb 2000 23:55:52 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: PDF problems
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
> > >http://www.ams.org/notices/200003/fea-landau.pdf
> >
> > I notice that URLs are occasionally provided directly to .pdf
> > documents. That will make them come up in the browser, which requires
> > both the browser and Acrobat Reader to be running at the same time,
> > which may lead to system crashes on older computers with less memory.
>
> I never get anything except a blank browser page from these even
> though I see the Acrobat Reader logo for a few seconds. What would
> cause this?
Netscape has an API which allows helper applications to display files
progressively as they are downloaded; I think there is a bug either in
Acrobat Reader's support for this API, or in Netscape's implementation of
it. (On my system it happens for some PDF files but not others, without any
obvious pattern.)
The only workaround I've found when this happens is to download the .pdf
file (for example by choosing File | Save As from the blank page), and
then open it in Acrobat Reader from the local disk.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOLcWSTkCAxeYt5gVAQF1lQf/aU/S1gbwq8PJZXF1EtvW8Ov9hFJjloDF
0epn59Odeg7ZbIEQaAy4Lhy5a4GTMshlGp8ehm7M6BLwnzLq1oPoCAdyh+F2axZn
5PmvwOzDrA/pbgCs7dVc0tMI7f2oJileolN4rGNkBxWhvheFr9ZB0zEkMCeA4N0Y
bjISO5y/Cr6lXZvqcwHLeteeQ52nqmgzSVjAzSlYr9ZfwLTLZgbmo1TTEZoCZuI2
/21VilpX/t6rWSgbZPijgbO0Rple2PNbBBW1KS0q5bq8fNrXKQzZuXtvBfcEwq2S
nYTziUYFWsOHNlDPjmwYI3L+9vGDYCzS4joul8lbCwEKa6IzycS+jw==
=mRuf
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Walter Roberson)
Crossposted-To:
alt.security.pgp,alt.security.scramdisk,comp.security.misc,comp.security.pgp.discuss
Subject: Re: Are "self-shredding" files possible?
Date: 26 Feb 2000 00:28:20 GMT
In article <XEEt4.8614$[EMAIL PROTECTED]>,
Thomas Moore <[EMAIL PROTECTED]> wrote:
:Does anyone know if it's possible to make a file "self-shredding?" I'm
:thinking of something along the lines of PGP's self-decrypting file type.
:I'm a regular on the groups that this question is posted to and have never
:read about this topic.
:I imagine being able to add or tag the "self-shredder" to a file, then
:letting the user (this could be password protected or not) shred it after
:any number of uses, or maybe after just one use. Files could also self-shred
:after a certain time period - run them after such and such date and they
:would just shred.
:Maybe this idea just isn't possible. I'm not a programmer so I really don't
:know. Please reply if you have any feedback.
We have discussed this in comp.security.misc within the last few months.
You might not have recognized it as such though, as we didn't use the
phrase "self-shredding". Please see the enclosed back postings.
http://www.deja.com/getdoc.xp?AN=568895489
Newsgroups: comp.security.misc
Subject: images
Date: 01/06/2000
Author: Walter Roberson <[EMAIL PROTECTED]>
In article <850g7u$1ov$[EMAIL PROTECTED]>,
sandokan <[EMAIL PROTECTED]> wrote:
:is there a way to encode an image so that it is no more readable (with any
:kind of software) after a certain period of time? A sort of countdown of an
:image file so that it's corrupted after, say, 1 hour from upload (or
:download).
We went through this in reverse about the end of November. The query then was
whether it was possible to create an encryption which would prevent EVERYONE
(including the creator) from accessing the file contents until a certain time
had passed. The answer then was NO: without hardware assistance, it is not
possible for pure software to be SURE that the hardware is telling it the
right time.
Your query has the same flaw as the query before had. You specified "with any
kind of software"; the previous query used the phrase "impossible". If you
were content with 99.99% protection, or with some reasonable limitation like
it costing at least 2 trillion lira to develop a method of bypassing the
protection, then we might be able to suggest some feasible methods. When you
say "ANY" kind of software, then you are asking for protection against all
POSSIBLE attacks, no matter how expensive or time-consuming, whether those
attacks be known now or if they will not be developed for another half million
years of study of pure mathematics. We just can't give you assurances against
what cannot happen in the future.
http://www.deja.com/getdoc.xp?AN=551884245
Newsgroups: comp.security.misc
Subject: Re: Control Piracy
Author: Walter Roberson <[EMAIL PROTECTED]>
Date: 1999/11/23
In article <[EMAIL PROTECTED]>,
Venson Yap <[EMAIL PROTECTED]> wrote:
:I am interesting in the way to preventing the software to be copied
:pirated.
:Any one having suggestion on that please contact me through the following e-
:address
We discussed this issue in a slightly different context about 2 months
ago in this news group (the issue then was time-locking encrypted messages);
our eventual decision was that this is extremely difficult without hardware
support. If you don't have hardware support [such as having the CPU
instruction set itself be encrypted through a quantum-hardware one-time
pad back to the software developer's site] then you cannot be sure whether
any result you get back from outside the CPU is real or faked. If all
external stimuli might be false, then you cannot be sure whether
this is a legal copy of the software, or a pirated copy whose inputs
[including the clock] are being manipulated to force it through a known
path that all the responses have already been recorded for.
The situation is not unlike the philosophical concept of solipism:
how do you KNOW that the world really exists, considering that all
you have to go on is your senses and your senses can certainly be
presented with false information ?
So... I'm afraid that you only have a few choices:
A) Make it computationally infesible under current technology to break
your copy scheme -- understanding that if someone cares to expend
enough resources, they WILL be able to break it;
B) Make it commercially infesible to pirate your software, by offering
it for a lower price than anyone who copies it could possibly match
(e.g., you pay people large sums of money to get the licensed software
directly from you: as long as you expect people to pay -you- for the
software, there is economic incentive to pirate it.)
C) Make your software so bug-ridden or useless or unfriendly that no-one
would WANT to pirate it.
------------------------------
From: "Chuck Davis" <[EMAIL PROTECTED]>
Subject: 235 and counting
Date: Fri, 25 Feb 2000 17:02:09 -0800
The code below has been up on the discovervancouver.com page for 235 days,
and no one has solved it yet.
The jackpot currently stands at $3,388.77 Cdn.
If you crack it before anyone else you will win the amount of money shown at
the time you send in your correct entry. The jackpot goes up by 1 cent a
minute until the code is cracked.
The solution is a single sentence taken at random from a renowned English
language encyclopedia.
Punctuation is ignored. No hints will be given, no correspondence will be
entered into.
To win you must write out the sentence in full and EXPLAIN how you Cracked
the Code!
Send your answer to: [EMAIL PROTECTED]
On your mark! Get set! Solve!
82 44 22 67 83 11 35 93 52 11 51 64 71 45 15 31 94 51 66 32 58 93 83 15 52
77 94 21 47 96 34 22 71 56 22 63 82 48 23 31 85 73 16 39 72 15 11 55 47 96
34 22 71 51 26 91 95 12 16 92 91 19 12 35 71 54 33 23 11 96 31 31 73 82 91
33 79 82 34 52 81 78 52 75 31 27 72 93 95 22 57 92 93 79 22 59 17 96 35 11
73 51 27 93 96 15 35 37 87 18 54 71 54 14 33 92 76 71 16 67 95 71 37 39 95
46 11 93 82 44 29 57 44 71 91 13 15 56 23 35 71 14 55 94 66 35 17 54 13 91
71 72 26 39 85 17 58 87 91 18 46 84 51 47 17 58 48 96 66 21 47 77 33 33 72
52 27 38 95 71 37 51 46 82 33 24 59 31 85 14 53 87 38 33 13 84 53 44 16 66
77 15 57 85 35 11 71 94 98 51 83 11 33 91 94 15 27 92 51 27 42 93 65
No gimmicks, no commercial tie-ins, nothing to buy, no surprises. Solve it,
tell me how you did it, win. It's that simple.
Chuck Davis
------------------------------
** 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
******************************
