Cryptography-Digest Digest #701, Volume #13 Sat, 17 Feb 01 14:13:01 EST
Contents:
Re: Hardware RNG - Where can I order one? (Janusz A. Urbanowicz)
Re: Big Numbers in C/C++ (Paul Schlyter)
Re: Big Numbers in C/C++ (Paul Schlyter)
Re: My encryption system..... (Richard Heathfield)
Re: is compression necessary when using gpg (GNU Privacy Guard)? (Janusz A.
Urbanowicz)
Re: Ciphile Software: Why .EXE files so large (phil hunt)
�������� �� ������ �� ������ ("�� "�������"")
Re: CipherText patent still pending (Benjamin Goldberg)
Could someone compile it for me? ("Ryan M. McConahy")
Re: National Security Nightmare? (Mok-Kong Shen)
Re: "RSA vs. One-time-pad" or "the perfect enryption" ("Sebastian Gottschalk")
Re: Super strong crypto (Steve Portly)
Re: Digital signature w/o original document ("David Sowinski")
Re: Big Numbers in C/C++ (D. J. Bernstein)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Janusz A. Urbanowicz)
Subject: Re: Hardware RNG - Where can I order one?
Date: 17 Feb 2001 00:50:59 +0100
Reply-To: [EMAIL PROTECTED]
Paul Rubin <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Janusz A. Urbanowicz) writes:
>
> > "The Death" <[EMAIL PROTECTED]> writes:
> >
> > > Where can i buy a good hardware RNG that i can connect to my PC and use to
> > > generate secure random bits?
> >
> > Get a motherboard that is Intel 810 or 815 based. It has one.
>
> Is there a simple way to tell if my mb supports this? It's a Thinkpad
> a20p laptop, PIII processor.
Probably it is not. Under Windows try checking what PCI chipset drivers are
installed. Under Linux, examine /proc/pci.
Alex
FUT: poster
--
======= Janusz A. Urbanowicz, Thawte WOT Notary, ALEX3=RIPE =========
There were cowboys ever since there were computers. They built the first
computers to crack German ice, right? Codebreakers. So there was ice before
computers, you wanna look it that way. -- William Gibson, 'Count Zero'.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Big Numbers in C/C++
Date: 17 Feb 2001 09:27:44 +0100
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Paul Schlyter wrote:
>> I also believe MIRACL is somewhat more accurate - why? Because it
>> implements reals not as the usual floating-point numbers but as
>> rational numbers: A/B where A and B both are integers. ...
>> MIRACL includes a full set of transcendental functions
>> (logs/trigs/etc) for MIRACL hi-precision real numbers.
>
> Pray tell, how does MIRACL represent sin(1/2), log(5), etc.?
> Those are not rational numbers.
Such numbers are represented by the closest possible rational
number within the overflow limits of the MIRACL big integers.
Consider for instance 355/113, which is accurate to 7 decimal digits
as a representation of Pi, even though these two numbers use only 6
digits total. In binary, 355/113 represents Pi to 24 bits of
precision, even though 355 uses only 9 bits and 113 uses 7 bits, a
total of 16 bits! If you instead had used a normal floating-point
representation of Pi, you would really need 24 bits of mantissa to
get 24 bits of precision (plus some additional bits for the exponent).
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: Big Numbers in C/C++
Date: 17 Feb 2001 09:29:12 +0100
In article <[EMAIL PROTECTED]>,
David Sowinski <[EMAIL PROTECTED]> wrote:
>> I also believe MIRACL is somewhat more accurate - why? Because it
>> implements reals not as the usual floating-point numbers but as
>> rational numbers: A/B where A and B both are integers. Which means
>> you can divide a MIRACL real with 3, 7, 10, 11, 13, etc and then
>> multiply the quotient with the same number and you're almost always
>> guaranteed to get your exact original number back. This works as
>> long as neither of A and B overflows (and since both A and B are "big
>> integers", they won't overflow very soon). If A, or B; or both
>> should overflow, MIRACL transforms A and B into smaller numbers such
>> that the new A/B is an approximation as close as possible to the
>> actual A and B - the final result is then no longer exact, of course,
>> but it's still as accurate as a regular floating-point implementation
>> of the same number of bits.
>
> Hmmm... "almost always guaranteed" So, what's the advantage?
Improved accuracy in many real-world cases -- quite often exact results
where binary f.p. or BCD yield only an approximate result.
Remember the arguments for BCD arithmetic over binary floating-point
arithmetic? These arguments are often brought up by business people
who may want to multiply and divide by even powers of 10 and always
get an exact result. Binary f.p. arithmetic often introduces small
round-off errors when you divide a number by 10, but in BCD arithmetic
this doesn't happen. But if you were to divide with e.g. 3, or 11,
or 13, or some other number besides 10, then BCD arithmetic will
introduce round-off errors too.
With rational arithmetic you can divide by ANY integer and then
multiply it back and get an exact result (unless the numerator or
denominator overflows, which almost never happen in e.g. checkbook
calculations).
Also: rational aritmetic appears more economic than binary f.p.
arithmetic in getting as much precision a spossible out of your bits.
Consider for instance 355/113, which is accurate to 7 decimal digits
as a representation of Pi, even though these two numbers use only 6
digits total. In binary, 355/113 represents Pi to 24 bits of
precision, even though 355 uses only 9 bits and 113 uses 7 bits, a
total of 16 bits! If you instead had used a normal floating-point
representation of Pi, you would really need 24 bits of mantissa to
get 24 bits of precision (plus some additional bits for the exponent).
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
Date: Sat, 17 Feb 2001 09:42:28 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: My encryption system.....
Keill_Randor wrote:
>
> It seems that you are all ignoring my challenge.. Oh well...
Challenges are generally a sign that you don't understand who reads
sci.crypt. Read the FAQ.
>
> The encryption system I have, (in a response to other posts on this board),
> IS different and a generation ahead of any other encryption system in the world
That's easy to claim and hard to prove. Read the FAQ.
> that I know of. Also, (in response to other posts), a one-pad cipher IS NOT
> the best system possible. Mine is.
Again, easy to claim and hard to prove. It is already known that OTP is
not perfect (although I believe it is agreed that, if the key is unknown
and the plaintext is unknown, then the very best the enemy can do is
randomly corrupt the message). Key distribution and bitflipping attacks
for known plaintext are both problems.
That one-time pads are not as perfect in the real world as they are in
theory does not imply that your system is better than a one-time pad.
Read the FAQ.
> To understand why that is the case, you
> have to understand exactly what data encryption is about in the first place.
I think there are plenty of people here who have a fair idea of what
data encryption is about. Read the FAQ.
> This seems to be the number one problem with everyone at the minute:
> No-one understands the problem, so no wonder nobody, (apart from myself),
> has actually solved it.
So you have solved a problem that only you understand, and in which
nobody else is the slightest bit interested? Read the FAQ.
> All data encryption is about is changing a peice of information into another, in
> such a way as to allow you a) to get it back later, and b) stop any
> 'unauthorised' people finding out what it originally was.
This earth-shattering conclusion is already known to most people in
sci.crypt. Read the FAQ.
> The ULTIMATE
> solution, therefore, is to split a peice of information into two or more
> EXISTING (innocuous) peices of information that CANNOT INDIVIDUALLY BE PROVEN
> TO BE ENCRYPTED..................
What cryptanalysis have you done on this? How does it stand up to
known-plaintext attacks, for example? What is your splitting algorithm?
Read the FAQ.
> My system at it's best can do this, (Though I have no doubt that it will be
> very difficult).
Is it even worth writing? Find out, by explaining exactly what you
intend. Read the FAQ.
> The by-product of this, is being able to turn ANY peice of information into ANY
> peice of information, which again, makes it uncrackable. (And completely screws
> up a lot of laws I know about).
"Uncrackable" is easy to claim and hard to prove. Read the FAQ.
>
> At it's best, (if splitting it into two or more existing peices isn't possible),
> my system can do a:
>
> Compound, non-repeating, multiple solution, multiple key, multiple algorithm,
> mutiple dimension, multiple depth, variable size encrypt, with multiple phase
> and multiple direction encoding, and (optional) Multiple variable ciphers....
>
> Trust me, if I encrypted something with all of this attached, then NO-ONE would
> ever crack OR solve it, without knowing EVERYTHING about it.
Whenever you say "Trust me", I say "Snake oil". Read the FAQ.
> Still looking for a job..... (Any offers???). (I cannot drive though, and I am
> currently broke...).
Making yourself look clueless in sci.crypt isn't the best way to get a
job. Read the FAQ.
> (P.S. If no-one else has what I have, does that make me King Cryppie???).
No. Read the FAQ.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
------------------------------
From: [EMAIL PROTECTED] (Janusz A. Urbanowicz)
Subject: Re: is compression necessary when using gpg (GNU Privacy Guard)?
Date: 17 Feb 2001 10:45:11 +0100
Reply-To: [EMAIL PROTECTED]
jtnews <[EMAIL PROTECTED]> writes:
> Since gpg scrambles the bits to introduce more
> entropy into the data stream, does it make sense
> to compress large files beforehand?
> Do you wind up saving any space in the end?
By default GPG compresses the file before encryption. This is in compliance
with the standard it implements - RFC 2440. The default algorithm is deflate
(as in zlib).
Alex
--
======= Janusz A. Urbanowicz, Thawte WOT Notary, ALEX3=RIPE =========
There were cowboys ever since there were computers. They built the first
computers to crack German ice, right? Codebreakers. So there was ice before
computers, you wanna look it that way. -- William Gibson, 'Count Zero'.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: talk.politics.crypto
Subject: Re: Ciphile Software: Why .EXE files so large
Date: Sat, 17 Feb 2001 13:44:19 +0000
On Sat, 17 Feb 2001 16:02:35 +1300, Michael Brown <[EMAIL PROTECTED]>
wrote:
>> Have you considered using Python?
>>
>> It's designed for RAD programming like VB, but it is also platform
>> independent. It has very extensive documentation, both books and
>> online.
>Isn't it effectively interpreted? I've never used Python, but after seeing
>the shocking performance of VB when you try to do anything fast I have a
>great suspicion of interpreted languages.
Python. like Java is compiled to intermediate code which is then
interpreted.
It isn't as fast as C++, but I find it is fast enough for most uses.
--
*****[ Phil Hunt ***** [EMAIL PROTECTED] ]*****
"An unforseen issue has arisen with your computer. Don't worry your
silly little head about what has gone wrong; here's a pretty animation
of a paperclip to look at instead." -- Windows2007 error message
------------------------------
From: "�� "�������"" <[EMAIL PROTECTED]>
Subject: �������� �� ������ �� ������
Date: 17 Feb 2001 15:56:08 GMT
�� "�������" ���������� ����������� �������� ������� �
������ ����� ������� �� ������.
����� �� ������ ���������� �������� �� ������, � �������
������� �������� ����� ���� ��������, � ��� �� ���أ
(�������������� �����). ���������� �� ������: �.
�����������, ��. ���������������� 19, ����� �����������, �
�-�� ����. �. 8(4232)46-72-89
e-m@il:[EMAIL PROTECTED]
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: CipherText patent still pending
Date: Sat, 17 Feb 2001 16:35:22 GMT
Douglas A. Gwyn wrote:
>
> Benjamin Goldberg wrote:
> > Douglas A. Gwyn wrote:
> > > I don't think that approach would help much. Consider that so far
> > > as we know, P = NP but we haven't found any proof of it yet.
> > > Oops, did all our ciphers just fall apart? No.
> > Who is this "we" that "knows" that P = NP?
>
> That isn't what I said. Try to understand what was said.
Please tell me how you intended the sentence "Consider that so far as we
know, P = NP but we haven't found any proof of it yet," to be parsed.
--
A solution in hand is worth two in the book.
------------------------------
Reply-To: <[EMAIL PROTECTED]>
From: "Ryan M. McConahy" <[EMAIL PROTECTED]>
Subject: Could someone compile it for me?
Date: Sat, 17 Feb 2001 11:37:05 -0500
Could someone with a C/C++ compiler compile MagicMoney for me for DOS?
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/applications/magic-money/MagicMo
ney.tar.gz
Thanks alot,
Ryan M. McConahy
[EMAIL PROTECTED]
ICQ# 81118154
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: Sat, 17 Feb 2001 19:04:35 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > ... In order to maintain the status quo,
> > a necessary condition, I believe, is that the common
> > people don't start to massively employ encryption, for
> > that would bog down all computing resources, unless
> > an extremely huge budget is available.
>
> Okay, now I get your point -- it's not that the content
> of Everyman's traffic is important, it's that picking out
> the intended targets' traffic might be harder. That is
> to some extent true, but the important factor lies in the
> routing protocols, not in message content. I think it
> will remain true for the foreseeable future that general
> Internet routing will expose enough information to make
> end-node targeting feasible. For it to be otherwise, the
> standards for routers etc. would have to require secure
> encryption of all address-related information, which
> would introduce a massive PK-management problem.
I still think that end-node targeting is at best of limited
value, because (1) there may be several e-mail addresses
for the same (real) recipient and getting new addresses
is normally rather easy, (2) the address can be in a
country not within the sphere of influence of the law
enforcement, (3) sending location can be neutral and
changing with time, (4) with (2) and (3) fairly flexible
communications are possible, (5) there are anonymous
remailers (I have no practical knowledge of their real
capability) and the like that obscure the traffic.
> > ... should or should not attempt to mobilize the
> > sensitivity of the public in matters of protection of
> > their privacy.
>
> The problem is, the ignorant public tends to get their
> "information" via what we call "the media", which rarely
> do a good job of explaining the important issues and
> recommended actions. Witness the outbreak of yet another
> Melissa-like Word (.vbs) virus. The public understandably
> are never going to learn enough to make their own
> rational decisions on such matters, so they rely on the
> experts to take care of these things for them, but the
> experts who should do that (e.g. Microsoft application
> developers) find that they are rewarded for producing
> flashy features much more than for producing improved
> security. So I don't think that addressing the end user
> is going to do much good. The problem lies in the middle
> of the development chain, and that is where security
> experts need to concentrate their influence.
You have accurately explained the situation. In the
current 'atmosphere', convincing an average private person
to protect his communications is probably next in difficulty
to converting him to a new religion. One possibility I
can imagine is that, as a by-product of security measures
developed in e-commerce, encryption facilities would become
ubiquitous and, as soon as the costs involved fall below a
certain threshold, these would be employed for ALL types
of communications 'naturally', much like one uses now
a PC and a word processor to write letters instead of
employing a type-writer.
> > Money always plays a role in this world that started with
> > sins. The fanatics have that and hence they can always get
> > some number of people willing to work for them, even if
> > 99.9999999......% of the population refuse.
>
> I don't see a connection between money and sin, but as to
> the fact that individuals vary and there will always be
> *some* who are willing to work for the Bad Guys, that's
> not a big problem so long as there aren't very many of
> them who are good at the technology. Small numbers of
> evildoers can be kept track of fairly well compared to
> large numbers (such as we created with our War on Drugs).
You are too optimistic. If newspaper reports are true,
in more than one cases a very small number of foreign
scientists sufficed to enable a country that was very low
in scientific and technical know-how to start projects on
missiles or even nuclear and biological weapons. The
war on drugs is, contrary to your view, almost lost.
A tiny indication of this is the news that I recently
read, saying that in Switzerland one can now cultivate
and buy cannabis legally. In Netherlands, the addicts
have since years been able to relatively easily and
legally get the stuffs they want, if I don't err.
M. K. Shen
------------------------------
From: "Sebastian Gottschalk" <[EMAIL PROTECTED]>
Subject: Re: "RSA vs. One-time-pad" or "the perfect enryption"
Date: Fri, 16 Feb 2001 14:54:33 +0100
"John Savard" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]...
> The only reason this works as a cipher system is because there happens
> to be a mathematical 'trick' it is based on.
That's what I mean.
Is there any mathematical 'trick' which works but has no trapdoor (like
factorization)?
And the only known answers all have the same problem: public and private key
are the same!
Any way out?
------------------------------
From: Steve Portly <[EMAIL PROTECTED]>
Subject: Re: Super strong crypto
Date: Sat, 17 Feb 2001 13:31:40 -0500
"Douglas A. Gwyn" wrote:
> "SCOTT19U.ZIP_GUY" wrote:
> > I am not sure this ["straw man" cipher] is reasonable. All
> > currently "blessed" ciphers have too short of a unicity distance ...
> > So called modern experts don't want to consider unicity distance
> > at all since it shows that modern block ciphers have the built
> > in information theoretical weakness.
>
> Um, yes, that's why I raised the issue. If we really want to
> investigate what it would take for "super strong crypto" we need
> to avoid assuming anything about a measure of "strength" that we
> assign to a system based solely on our own ignorance of appropriate
> cryptanalytic methods. All measures based solely on the infeasibility
> of searching the key space fall into that category, as do most other
> "combinatorial" arguments. That means we need to go back to basics
> and investigate the proper assessment of likelihoods based on
> information statistics. One sees little of that in the open
> literature (at least for cryptology; however, it is not so rare in
> other information-related fields such as communication theory).
>
> If such an investigation shows that the usual block-cipher systems
> cannot provide "super strong crypto", even with frequent key updates,
> as well it might, then getting people to appreciate that might help
> sell them on systems like scott19u. I think in many practical
> applications, a channel is going to have to start off with a
> relatively short secret key (say, 512 bits) and use some provably
> good way to "stretch" its secrecy. Thus my straw-man proposal.
The implementations that pop into mind would be temptingly easy to modify
into much stronger configurations. Unless there is some new breakthrough
that will balance the equation, I don't see an organization like NIST
approving such a cipher scheme?
------------------------------
Reply-To: "David Sowinski" <[EMAIL PROTECTED]>
From: "David Sowinski" <[EMAIL PROTECTED]>
Subject: Re: Digital signature w/o original document
Date: Sat, 17 Feb 2001 12:37:53 -0600
"David Sowinski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > > I am interested in generating a digital signature that can later be
> verified
> > > without the original document. I recall coming across a homomorphic
> > > encryption/signature scheme awhile back, but cannot find much
> information on
> > > it now. Does anybody know if this is possible?
> >
> > I must be missing something. If you don't have the original document,
how
> > do you know what you are checking the signature of?
>
> Maybe I am completely whacked! It certainly doesn't make any sense... For
> some reason, though, I recall a scheme that validated information, as well
> as hid the information -- maybe it was actually using the information
> without knowing it. Right now I cannot recall the details and cannot find
> the papers. From what I do recall, there were a few examples how the
scheme
> could be used: One was related to using a formula to solve problems
without
> actually knowing the formula and the other was related to software
> protection. At any rate, and like I said before, maybe I am completely
> whacked.
I found a couple of the papers (Christian Cachin, Efficient Private Bidding
and Auctions with an Oblivious Third Party, IBM Research Division, 1999 and
Tomas Sander & Christian Tschudin, On Software Protection Via Function
Hiding, ICSI, 1998). Sorry about the confusion.
Regards,
-dave
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Big Numbers in C/C++
Date: 17 Feb 2001 18:58:15 GMT
Dann Corbit <[EMAIL PROTECTED]> wrote:
> How does GMP compare to Freelip? Has anyone actually done benchmarks?
http://cr.yp.to/speed/mult.html
---Dan
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
