Cryptography-Digest Digest #140, Volume #11 Thu, 17 Feb 00 08:13:02 EST
Contents:
Re: OAP-L3 Encryption Software - Complete Help Files at web site ("ink")
Re: EOF in cipher??? (Runu Knips)
Re: EOF in cipher??? (Runu Knips)
Re: Does the NSA have ALL Possible PGP keys? (Johnny Bravo)
Re: OTP practical implementation (Johnny Bravo)
Re: OTP practical implementation (Johnny Bravo)
VB & Crypto (Khalil Haddad)
Re: Q: Division in GF(2^n) (Runu Knips)
Re: OAP-L3 Encryption Software - Complete Help Files at web site (Tony L. Svanstrom)
Re: Large Floating Point Library? (Runu Knips)
Re: NIST, AES at RSA conference (John Savard)
Re: NIST, AES at RSA conference (John Savard)
Re: VB & Crypto (Runu Knips)
Re: RSA Speed (Tom St Denis)
Re: Does the NSA have ALL Possible PGP keys? ([EMAIL PROTECTED])
Re: Does the NSA have ALL Possible PGP keys? ("Juergen Nieveler")
Re: Question about OTPs (Johnny Bravo)
Re: Does the NSA have ALL Possible PGP keys? ([EMAIL PROTECTED])
Re: Question about OTPs (Johnny Bravo)
Re: Using virtually any cipher as public key system? (Tom St Denis)
Re: free C crypto API (Tom St Denis)
Re: Question about OTPs (Dave Hazelwood)
----------------------------------------------------------------------------
From: "ink" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Thu, 17 Feb 2000 11:15:02 +0100
Anthony Stephen Szopa schrieb in Nachricht ...
>All right, Emeritus Fool.
Keep cool. Please.
>A musical score can be precisely described mathematically yet it came into
>being from the creative mind of a composer. Or are you claiming that a
>composer used a mathematical equation to compose the music?
I think that can hardly be compared. Stick to the topic, okay?
>Why are people using OAP-L3 encryption software with no complaints?
Because
>they are more than satisfied: that's why.
IMHO that might also be because no-one tried to attack OAP-L3 so far. Or
have there been serious attacks that the system would withstand? Please
inform us about that. No need to get all worked up.
Kind regards,
Kurt
“Intelligence is when you spot the flaw in your boss’s
reasoning. Wisdom is when you refrain from pointing
it out.” - James Dent
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Thu, 17 Feb 2000 11:34:44 +0100
Mok-Kong Shen schrieb:
>
> Stephen Houchen wrote:
> >
>
> > If you're programming in C, open the file as "binary" (mode "rb", for
> > example).
>
> I am ignorant of what the C standard specifies. Question: Does
> 'binary' require the file to be multiple of words or just any multiple
> of bytes will do? Thanks.
>
> M. K. Shen
The only thing which is different from text mode is, when you compile
your program in an environment, where end of line isn't a single
character, it will be mapped into a single character '\n'. This is true
for CP/M and its successors (MSDOS, PCDOS, DRDOS, MS Windows, IBM OS/2),
where end of line is represented as cr+lf (13dec, 10dec) and will be
mapped into lf (10dec).
Has nothing to do with word size. The files are still a byte stream :)
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Thu, 17 Feb 2000 11:38:42 +0100
JPeschel schrieb:
>
> "Douglas A. Gwyn" writes:
>
> >When reading random bit patterns, the program should not perform any
> >text format interpretations. In C, the file should be opened as a
> >binary stream, not a text stream.
>
> And use FEOF to detect the end of the binary file being read.
FEOF is not standard. Which compiler defines such a strange variable ?
EOF works well, because EOF is defined to be -1, while all characters
are returned as nonnegative values.
If you want to read binary data, use fread (buf, 1, 1, file). It reads
always in the 'binary' way no matter if you have opened the file in
text or binary mode. You cannot open file in binary mode on some unix
systems (they simply fail to open if 'b' is in the open specification,
even if that conforms not to ISO C), so this is the portable way.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 05:42:21 +0000
On Wed, 16 Feb 2000 12:07:11 -0800, "tiwolf" <[EMAIL PROTECTED]> wrote:
>Anything is possible given time, money, and talent.
How many times are you going to post this blatant stupidity?
Many things are 100% impossible, finding the biggest number for
instance. Get this through your head; some problems do not have a
solution to find.
>Government has nothing to do with it. In this case the government desire
>to control along with access to money (tax payers), and (through the obscene
>spending of the taxpayers money) talent.
Make up your mind, does government have something to do with it or not?
Makes no difference, impossible is just that, impossible. Even with
infinite time, money and talent. Not even God can tell you what the
biggest number is.
Johnny Bravo
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: OTP practical implementation
Date: Thu, 17 Feb 2000 05:48:02 +0000
On Wed, 16 Feb 2000 13:32:10 -0500, Paul Koning <[EMAIL PROTECTED]>
wrote:
>Johnny Bravo wrote:
>> It would be easiest to send it in the clear as the start of the message
>> as a 4 byte value, and would not leak anything unless you have an extra
>> copy of the CDs floating around somewhere unaccounted for. In which case
>> the offset is not enough security, and a secondary password might be
>> helpful if you have such a need for security.
>
>No, actually... if there's an unaccounted copy of the CDROM somewhere,
>you've lost all security. If the bad guy has that CDROM, he can simply
>try XORing your ciphertext at all possible offsets looking for
>plaintext, that won't take long at all.
That was the point I was making. I stated that sending the offset in
the clear would not affect security, unless a CD is missing. I realize
that a missing CD would be a "Bad Thing(tm)".
If that (a missing CD) is a concern I suggested a secondary encryption,
with a shared password to be used as backup. RC4 would be ideal, using
the offset as the IV. It would help reduce the problem of a missing CD,
since if the CD goes missing all prior traffic becomes vulnerable. My
apologies if I wasn't making myself clear enough.
Best Wishes,
Johnny Bravo
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: OTP practical implementation
Date: Thu, 17 Feb 2000 05:51:20 +0000
On Wed, 16 Feb 2000 19:22:51 GMT, [EMAIL PROTECTED] (Jim)
wrote:
>Then it gets difficult......
>
>That system allows any one sender to read the traffic of any other
>sender, given that he can intercept other senders' traffic.
>
>It becomes much more hairy if traffic between two senders must be
>secure from other senders.
That is why OTPs aren't normally used, it requires one pair of CDs for
every set of senders and recipients, gets bulky after a while. I was
letting the person with the CDs worry about the distribution and contents
of the set.
Best Wishes,
Johnny Bravo
------------------------------
From: Khalil Haddad <[EMAIL PROTECTED]>
Subject: VB & Crypto
Date: Thu, 17 Feb 2000 11:55:56 +0100
Hello all,
I am developping softwares in VB6 and would like to use strong
encryption algorithms.
Anyone could tell me where to find sources in VB so that I can study
them.
thanks
Khalil Haddad
KFSoft
http://kfsoft.cjb.net
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Q: Division in GF(2^n)
Date: Thu, 17 Feb 2000 12:04:27 +0100
Mok-Kong Shen schrieb:
> Paul Koning schrieb:
> > Well, certainly patenting mathematics is as absurd as patenting
> > genetics, but both seem to be permitted by the US patent office
> > these days. [...]
> > But you don't need to worry about most of the cases you mentioned.
> > School math is clearly not patentable -- it's not "novel". [...]
>
> I am not quite sure of that. I can't see e.g. that using the relation
> 1/B = B^(2^n-2) is anything that qualify as 'novel' at all. (It is
> one of the 'basic' facts that the order of a non-zero element divides
> p^m-1 in GF(p^m).) The situation as I perceive is the following:
> There has been in the past some number-theoretic operations that
> got patented. Because of such 'precedences' the patent office
> has difficulties to refuse other number-theoretical stuffs to be
> patented also, even these are very trivial. If that practice
> continues, one ends up with virtually all the mathematical
> computations in practice patented. This is in my humble view a
> very serious and critical issue, having, I believe, a very far
> reaching impact on the society. (Doesn't everything in the modern
> world depend on mathematics?) [...]
But patenting mathematics is essentially the same as patenting
software, which is possible in the U.S., too ! If you state that
mathematic ideas shouldn't be patentable, you have to say also
that algorithms can't get patented, don't you ? At least I can
see no basic difference between these two. Where is there the
frontier ?
Patenting genetics is only the final step. I think if I find
a new star or a new animal, I'll try to patent them, too. Oh
I'm becoming sarcastic...
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Crossposted-To: talk.politics.crypto,alt.privacy
Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
Date: Thu, 17 Feb 2000 12:15:12 +0100
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
> Why are people using OAP-L3 encryption software with no complaints?
They use Windoze to... enough said. *EG*
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---ôôô---ôôô-----------------------------------------------ôôô---ôôô---
\O/ \O/ ©1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Large Floating Point Library?
Date: Thu, 17 Feb 2000 12:27:45 +0100
Dann Corbit write:
> C++:
> MIRACL by Scott [...] Good for several hundred digits. [...] It is free
> for academic use and has a one time $500 charge for commercial use (last
> time I looked).
>
> QFLOAT by Moshier is very good for up to 50 digits or so. [...]
>
> APFLOAT by Tommila and HFLOAT by Arndt are good for thousands of digits, but
> require GCC [...]
Well all nice, but ever heard of links ?
MIRACL: http://indigo.ie/~mscott/ [commercial, free for
.edu]
QFLOAT: <- not found yet ->
APFLOAT: http://www.jjj.de/mtommila/apfloat/ [free]
HFLOAT: http://www.jjj.de/hfloat/hfloatpage.html [GPL]
Took me only 5 Minutes to find these, but that where 5 Minutes wasted
time
which could have been spared, hmm ? QFLOAT results in many links to
FORTRAN
compilers etc, will take a longer while to find the real source...
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 17 Feb 2000 11:19:27 GMT
On Wed, 16 Feb 2000 16:05:38 GMT, [EMAIL PROTECTED] (Bo
Dömstedt) wrote, in part:
>A thing that I find disturbing is that NIST has removed ciphers
>from the list of AES candidates based upon poorly documented
>statistical tests. Statistical tests of ciphers yield results that,
>for some ciphers, could be correlated with the cipher
>quality/security. Generally, this do not hold. Is the selection of
>the five finalists to some degree based upon arbitrary decisions?
I'm not in full agreement with this paragraph, because there is a
reason why, although your statement that "this does not hold" is
correct, NIST's action (if they've taken this action: I hadn't heard
of it) is still valid.
Basically, although a cipher can still be badly insecure, and pass
statistical tests, the reverse, that a cipher can fail statistical
tests and still be secure (with the basic exception of ciphers that
expand the input, such that only the expansion - performed after
enough of the encryption to produce security - has statistical
regularities, which does not apply to AES-format block ciphers) is,
essentially, _not_ possible.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: NIST, AES at RSA conference
Date: Thu, 17 Feb 2000 11:30:59 GMT
On Thu, 17 Feb 2000 01:20:19 GMT, Bryan Olson <[EMAIL PROTECTED]>
wrote, in part:
>What part of your argument for
>tripling ciphers would not apply to a cipher with an
>internal structure that happens to already be a triple
>cipher?
Actually, quite a big part, since he is only incidentally arguing for
using three ciphers in a cascade, as a safety precaution in the use of
his actual proposal: to use different ciphers drawn from a relatively
large pool for each message, rather than using the same cipher all the
time. (A block cipher that is designed as a "triple cipher" would
still keep using the same three ciphers.) (But look at Quadibloc III,
which uses the same five ciphers in a data-dependent order!)
Without such safety precautions, the often raised argument that the
use of differing ciphers is as strong as the "weakest link" would be a
serious and effective objection, in my opinion, but the use of
multiple layers of ciphers addresses that objection.
I've proposed a further precaution of allowing more a complicated
constraint on the cascade of ciphers used - specifically, requiring
that a cascade include one cipher from a small list of highly trusted
or recognized ciphers - to more fully meet the objections commonly
raised to the proposal.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: VB & Crypto
Date: Thu, 17 Feb 2000 12:53:37 +0100
Khalil Haddad schrieb:
> I am developping softwares in VB6 and would like to use strong
> encryption algorithms.
> Anyone could tell me where to find sources in VB so that I can study
> them.
Ouch.
Better use a .dll with C routines, if you can.
VB is not meant for any serious programming task, and I don't
think anyone has ever written a cryptographic software in VB.
For example, VB doesn't have shift operations, does it ? And
its not very optimizing, so cryptography is slow with it.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RSA Speed
Date: Thu, 17 Feb 2000 11:53:55 GMT
In article <[EMAIL PROTECTED]>,
Erik <[EMAIL PROTECTED]> wrote:
> I wrote a program to do RSA with a 1100 bit modulus. I use 65537 for
> the public key exponent, and the private key exponent is, of course,
> near 1100 bits. It works, and encrypting with the public key takes
> about a quarter of a second, but decrypting with the private key takes
> 43 seconds on a 400 MHz Pentium. Does this seem right?
>
With a moduli that size decryption should take at most 5 seconds on
that type of cpu. What large integer package are you using? If it's a
homebrew maybe it's not optimal?
With MPI I can decrypt with 1024 bit keys in a few seconds, and I am
sure the hand optimized code in pgp can do it in a sec or so.
With my own home brew package [designed for portable embeded compilers,
email me: [EMAIL PROTECTED] if you want to see a copy] can do 512 modular
exponentation in about 10 seconds [this is in a 16 bit x86 target].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 12:01:12 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Mon, 14 Feb 2000 11:51:34 GMT, [EMAIL PROTECTED] wrote:
>
> >In article <[EMAIL PROTECTED]>,
> > Anonymous <[EMAIL PROTECTED]> wrote:
> >> There are a couple of interesting threads on talk.politics.crypto
> >> originating from a cryptographer with www.filesafety.com. They
> >> purport that the NSA has ALL POSSIBLE keys for PGP and that all PGP
> > ^^^^^^^^^^^^^
> >like all the emotionally-heated previous answers have made plausible, it
> >is very unlikely that the NSA stores all possible keys
> >
>
> Why would they want to STORE them? To what end? Pointless as
> well as impossible.
>
> Much easier just to run through each key hoping they hit the right
> one sometime before the sun burns out.
yep
> >- It is reasonable to assume that the NSA is able to run very fast and
> >exhaustive dictionary attacks against the passwords that secure the
> >private key.
>
> That's not quite the same thing as breaking the cipher, is it?
> If they wanted to do that, why would they bother generating
> and storing all the keys.
Well, I'm not sure if you've read my answer carefully. I was pointing out
to the original poster, that it's quite senseless for the NSA to generate
and store all keys (even if it was possible), just because they can
obtain *used* keys easily by side-channel attacks.
> >- It is reasonable to assume that the NSA is able to obtain any private
> >key stored on the harddisk of any individual at home, if he/she is the
> >specific target of an attack.
> Only by forcing a weak passphrase, or getting the suspect to reveal
> it.
No, this is absolutely wrong. It is easy to obtain the passphrase by
installing a keystroke logger or by using Van Eck devices, and it's easy
to obtain the private key by all different kind of means from physical
access to the harddisk to Trojan horses / viruses.
> >2. There's a possibility to some degree merely depending on the NSA's
> >will to break the law (and eventually be catched while doing this), that
> >the NSA is able to read almost any mail encrypted by PGP, because they
> >have obtained the key and password of most PGP users by side-channel
> >attacks.
>
> They've obtained the keys and passwords of absolutely EVERYONE.
Just above, I've said "..of most PGP users.." Why do you write
"absolutely EVERYONE"? Can't you read?
> world-wide, who uses PGP. Aw, come on!! Their budget and staffing
> stretch that far?
That's what I was talking about: You do not need a budget and staffing
stretched far for this. In fact, *one* single person can write a suitable
virus or Trojan horse within one or two weeks. It is also trivial to
launch such tools, and although it poses serious problems for an
individual to hide the original source of the virus/Trojan horse, this *
certainly* is not a problem for any of the large government agencies.
So it is pretty pointless for any agency to try to break the encryption
of tools like PGP, because it's easier to obtain the keys by side-channel
attacks.
Greetings,
John Stone
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Juergen Nieveler" <[EMAIL PROTECTED]>
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 13:10:21 +0100
"Johnny Bravo" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
news:[EMAIL PROTECTED]...
> On Wed, 16 Feb 2000 12:07:11 -0800, "tiwolf" <[EMAIL PROTECTED]> wrote:
>
> >Anything is possible given time, money, and talent.
>
> How many times are you going to post this blatant stupidity?
>
> Many things are 100% impossible, finding the biggest number for
> instance. Get this through your head; some problems do not have a
> solution to find.
>
> >Government has nothing to do with it. In this case the government desire
> >to control along with access to money (tax payers), and (through the
obscene
> >spending of the taxpayers money) talent.
>
> Make up your mind, does government have something to do with it or not?
> Makes no difference, impossible is just that, impossible. Even with
> infinite time, money and talent. Not even God can tell you what the
> biggest number is.
>
> Johnny Bravo
>
No, but HE could change the world so that there is such a thing as a
"biggest number".
Of course, that would be cheating :-)))
CU
Juergen Nieveler
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 07:11:55 +0000
On Wed, 16 Feb 2000 16:09:44 -0500, Arthur Dardia <[EMAIL PROTECTED]>
wrote:
>Many people attempt to pack CD-ROM's with totally random data; however,
>then you must tell your recipient which offset to start reading the pad
>from. So, my question is this: for one message, so that I start at the
>30,567,890 byte and the next I start tat the 30,567,889. While this is
>only one byte off, the ciphertext is totally different; however, how
>secure is this?
This is nearly 100% insecure, you never reuse the random data. Use each
byte one time only or you are not using OTP, you might as well just ROT13
it.
>While most of the padding is identical, will pushing the offset back one
>byte still aid cryptanalysts in cracking the message?
If you are using the standard XOR, it will allow complete recovery of
everything but one byte in either the first message sent on that disk or
the last (depending on which direction you come from). Not exactly what
you had in mind.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Thu, 17 Feb 2000 12:10:38 GMT
> This is a claim distinct from the statement that NSA has "all possible
> keys". It amounts to the claim that the NSA has or can obtain all keys in
> use. While this claim cannot be refuted by size-of-the-universe
> calculations, it still requires substantial support to be credible.
>
> To me it looks pretty nekkid.
Well, any basic skilled hacker can get *your* private key plus keyphrase,
and so probably does the NSA. See my other reply for an explanation why.
It's another question wether the NSA does actively collect anyone's keys
without the person being a special target. I am not an American and I
must admit that there's a strange paranoia of US citizens towards their
own agencies. I have no clue why the people always fear the NSA and not
equivalent foreign agencies. Seems to have something to do with the
federal structure and the size of the USA, but this irrational distrust
against the government is something foreigners have problems to
understand.
Regards,
John Stone
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Johnny Bravo <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 07:20:13 +0000
On Wed, 16 Feb 2000 20:02:58 -0500, Arthur Dardia <[EMAIL PROTECTED]>
wrote:
>However, I might have come up with a work-around. One of the main
>ideals before OTPs is that the pad file must be kept secret.
And data is never reused.
> If it is
>successfully kept secret, then I should be able to store the offset's
>and ending offset for each encryption that was used in a log file.
>Then, when the user logs on, and he attempts to use an offset that falls
>within any of the ranges, it gives him a warning message that his
>ciphertext will become much easier to attack if he continues to encrypt
>with this offset.
If you want a real OTP, each user must get a block of bytes to use, let
the program keep track of which ones have been used already. When all the
bytes are gone, burn a new set of CDs. Using data twice and you no longer
have a OTP, and a real possibility of compromising data.
>However, if the pad file is not kept secret, this poses an attack
>because the attacker will not only know the pad file (thus making it
>easier to brute force it since he needs only to check every possible
>starting offset...about 650 million on a CD), he'll know exactly which
>offset yields the correct answer.
Pointless. The keyspace for 650mb of offsets is roughly 29 bits. Brute
force would take a few minutes on a good home machine. On a real computer
it would take a few hundredths of a second to check every possible offset.
--
Best Wishes,
Johnny Bravo
"The most merciful thing in the world, I think, is the inability
of the human mind to correlate all it's contents." - HPL
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Using virtually any cipher as public key system?
Date: Thu, 17 Feb 2000 12:20:44 GMT
In article <[EMAIL PROTECTED]>,
Anton Stiglic <[EMAIL PROTECTED]> wrote:
>
> --------------3D7C6BA71BE643ED4FB09901
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Mikko Lehtisalo wrote:
>
> > I read a long time ago some book and in it was the instructions how
to
> > use any algorithm (for instance des) as a public key system.. It
> > involved something like creating two keys and ciphering random data
> > and moving it blahblah.. Can't even remember what the technique is
> > called :( Any info?
>
> A simple way to achieve some kind of public key crypto using symmetric
> algorithms is by using a half-certified diffie-hellman static public
key
> agreement (sometimes called ElGamal key agreement, and a whole bunch
> of other variations of the key words).
> It simply goes like this:
>
> like in DH, there is a publicly known generator g,
>
> Alice computes g^a (for some randomly chosen a) and publicly publishes
> it somewhere (if you have signature schemes, she could sign it, but
that
> uses
> public-key crypto...).
>
> So now, when some guy, say Bob, wants to communicate with Alice,
> he simply takes g^a, computes (g^a)^b for some randomly chosen b
> and sends g^b to Alice. Alice, upon receiving this g^b, computes
> (g^b)^a (just like DH).
> (g^a)^b is now a shared secret, which can be used to generate a key
for
> a symmetric algorithm.
> If Carl also wants to communicate with Alice, he does the same thing.
> It's not asymmetric crypto, but its kind of public key crypto....
>
> This is actually what is used in the Freedom software (as described in
> the white paper)....
Actually what you described is public key cryptography. Where (g^a mod
p) is your public key and 'a' is your private key. Just because you
are not encrypting with it, does not mean it ain't PK.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: free C crypto API
Date: Thu, 17 Feb 2000 12:23:46 GMT
That's essentially my 'makefile.dj' which uses GCC on MS-DOS
platforms. I can include a generic GCC makefile though.
Thanks, btw CB V1.02 is out which 'hopefully' fixes a few bugs around
the base64 codecs etc..
Tom
> OOops, I don't have it at hand, but Unix Makefiles are easy:
>
> ______________________________________________
>
> default: all
>
> CC=gcc
> CFLAGS=-O3 -fomit-frame-pointer -funroll-loops -DNDEBUG
> AR=ar
> ARFLAGS=r
> RM=/bin/rm -f
>
> OBJS=idea.o <... add all object files as ".o" ...>
> LIB=libcryptobag.a
>
> all: ${LIB}
>
> ${LIB}: ${OBJS}
> ${AR} ${ARFLAGS} $@ ${OBJS}
>
> clean:
> ${RM} ${OBJS}
>
> distclean: clean
> ${RM} ${LIB}
>
> idea.o: idea.c idea.h <... add all include files included by
idea.c ...>
> <... the same for all other object files ...>
> ______________________________________________
>
> Just replace the <... ...> comments with what's described there. Hmm
> I've
> to get the libary from home. THe main problem was, there was already a
> "makefile", but it was from dos or windows.
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: Re: Question about OTPs
Date: Thu, 17 Feb 2000 12:28:52 GMT
Surely you mean never reuse a byte "sequence" as opposed to "no"
byte?
Since there are only 256 different bytes possible in an 8 bit word
you are not going to get very far beyond sending one short message
for all time. :))
[EMAIL PROTECTED] (Bill Unruh) wrote:
>In <[EMAIL PROTECTED]> Arthur Dardia <[EMAIL PROTECTED]> writes:
>
>In a OTP, no byte of the one time pad should ever be reused in any way.
>If a byte is used for any purpose, throw it away and never use it again.
>That is the condition under which a OTP is secure. Anything else and the
>security proof fails. Of course one may be able to argue that some ways
>of reusing the byte are still secure enough, but that is a different
>argument. To be a One Time Pad, the One Time is crucial.
>
>
------------------------------
** 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
******************************
