Cryptography-Digest Digest #154, Volume #11 Fri, 18 Feb 00 19:13:01 EST
Contents:
Re: VB & Crypto (Glenn Larsson)
The Online Banking Flaw... (John Savard)
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: VB & Crypto (Jerry Coffin)
Re: code still unbroken ("Chuck Davis")
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: EOF in cipher??? ("Trevor Jackson, III")
Re: Processor speeds. ("Trevor Jackson, III")
Re: Keys & Passwords. ("Trevor Jackson, III")
Re: Question about OTPs (Bryan Olson)
Re: VB & Crypto ("Brian Bosh")
Re: Using virtually any cipher as public key system? (Anton Stiglic)
Re: Question about OTPs (John Savard)
Re: Question about OTPs (Bryan Olson)
Re: EOF in cipher??? (JPeschel)
Re: NSA Linux and the GPL ("Adam Durana")
Re: VB & Crypto ("Joseph Ashwood")
Re: Using virtually any cipher as public key system? (John Savard)
NIST publishes AES source code on web (David Crick)
Re: VB & Crypto ("Kasper Pedersen")
Re: EOF in cipher??? (John Myre)
Re: EOF in cipher??? (John Myre)
----------------------------------------------------------------------------
From: Glenn Larsson <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 22:09:40 +0100
[EMAIL PROTECTED] wrote:
> Well then you'll be happy to know that VB7...
Have MS invented large integer support yet or are we still in the
stonage with the 2^32 limitation? (i mean HELLO! it's Y2K ALREADY!)
(at least Bill learned that "640 kb" lession...)
I'm personally tired of all the pointless features Ms is putting
into VBA instead of developing it so one can use it for what's
discussed in this channel, hence VB apps can never be secured.
(VC++ really could use a 2^128 boost too..)
/Glenn
_________________________________________________
Spammers will be reported to their government and
Internet Service Provider along with possible legal
reprocussions of violating the Swedish "Personal
Information Act" of 1998. (PUL 1998:204)
This is punishable by a fine or 6 month to 2 years
imprisonment (Paragraph 49)
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: The Online Banking Flaw...
Date: Fri, 18 Feb 2000 14:40:39 GMT
In the latest Crypto-Gram, we have a story about a firm that offered
online banking services.
One could start an account with a bank transfer, and to get money
withdrawn from your bank account, all you needed to do was supply the
account number, and other numbers visible on checks for that account.
Now, it is clear the firm did make a bad decision, in that not
requiring more proof of account ownership allowed fraudulent
transactions.
However, since the firm *didn't* have proof people wanting to transfer
money from a bank account to the firm had the right to withdraw money
from those accounts, why is it the firm was able to _get_ that money
from the banks, since, if it didn't recieve the proof from the people
opening accounts with them, obviously it didn't have that proof to
show to the banks? To me, therefore, it seems that there is a
fundamental vulnerability in the whole banking system, without which
X.com would not have had the _opportunity_ to make the mistake that it
did.
Because of this vulnerability, one can still withdraw money from
anyone's account with just the numbers on the bottom of his check: but
instead of opening a new account with an online banking company, one
just has to go to a little more trouble: one has to start one's own
online banking company.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Fri, 18 Feb 2000 16:49:42 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Mok-Kong Shen wrote:
> Runu Knips schrieb:
> >
> > "Trevor Jackson, III" schrieb:
> > > Mok-Kong Shen wrote:
> > > > To be sure that I didn't misunderstand, I like to ask whether the
> > > > code (from KR):
> > > > while ((C = getc(fp)) != EOF)
> > > > .........
> > > > needs to be modified or using rb is sufficient for taking care of
> > > > the presence of any bit combinations in the file. Thanks.
> > > The issue is the type of the variable C. To operate correctly it must
> > > be an int not a char.
> >
> > Unfortunately, the above code will run on many systems without
> > problems until fp is a binary file which happends to contain
> > the code 0xff, which is equal to (signed char)-1 (on machines
> > with 8 bits for a character).
>
> I have read quite a lot in this thread but, because of non-unanimity
> of opinions expressed, am still not sure of what is to be done
> correctly. Could some experts please post a piece of C or C++ code
> for writing AND reading binary stuffs to/from a file (byte sequences
> containing arbitrary bit combinations) that are standard conforming
> and guaranteed to work on all systems (together with things to be
> taken care of on the command level of the operating systems,
> if any). That would bring the discussions to a happy end. Thanks
> in advance.
int C;
while ((C = getc(fp)) != EOF) {
/* process character in C */
}
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 14:54:33 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Perhaps, but like the fighter pilots say
> -"It's not the plane that counts; it's the pilot"
...within limits. Put the best fighter pilot in earth into a WWI or
WWII era fighter and let him try to fight a mediocre pilot in an F-16
(or other modern fighter). When the fight's over, the mediocre pilot
can proudly proclaim that he just became the best fighter jock on
earth, and the one who used to be the best won't be around to argue
the point...
> (P.S: Likewise; as an ex ASM hacker, i could say that
> C++ is kidstuff)
I currently use both, and wouldn't say anything of the sort. I would,
however, say that VB's compiler has poor enough optimization that
you've got to do a LOT of extra work to make it keep up with even a
mediocre C++ compiler. Worse yet, it does its best to keep you using
threaded interpretive code instead of producing machine code, which
will slow most CPU-intensive code by a factor of 10 or so.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Chuck Davis" <[EMAIL PROTECTED]>
Subject: Re: code still unbroken
Date: Fri, 18 Feb 2000 13:56:12 -0800
Hi, Geoff: The download problem is a puzzler, and the first time I've seen
it mentioned. I'll alert the webmaster to the date problem, it's likely he
hasn't even noticed it. And as for nobody caring, for a chance to win $3,000
I think I could learn to care! Here's the puzzle..
<CODE author="Chuck Davis">
The solution is a single sentence taken at random from a
renowned
English language encyclopedia.
Punctuation is ignored.
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
Send your answer to: [EMAIL PROTECTED]
</CODE>
Geoff Lane <[EMAIL PROTECTED]> wrote in message
news:88jffe$lio$[EMAIL PROTECTED]...
> > Chuck Davis wrote:
> >
> >> Most of the correspondence I get from cryptanalysis folk about the code
I
> >> devised at discovervancouver.com sneers at its triviality.
>
> Perhaps nobody cares?
> Perhaps nobody has the patience to wait for the discovervancouver.com
> page to down load.
> Perhaps nobody can stop laughing at the Y2K bug the page still displays
> (Saturday, February 19, 100 indeed!)
>
> --
> Geoff. Lane. |
>
> In case of fire, yell FIRE!
------------------------------
Date: Fri, 18 Feb 2000 17:12:47 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > > Wrong. Bytes are written to binary files, characters to text files.
> >
> > Interesting. Tell me, just how do they do that on a machine that doesn't
> > _have_ bytes?
>
> The C standard apparently defines "byte" a bit differently than you
> do. According to the standard, all machines having conforming
> implementations of C MUST have bytes. Specifically, a "byte" is the
> amount of storage needed to hold one char.
Yes.
However, there exist machines with C compilers that were once standard, but are
no longer. Certainly, if you buy a new compiler you should expect to find it
in conformance with recent changes to the standard (C99 may be a little young
though).
However, the fact that standards change does not mandate changes to existing
software or software tools. Indeed, such changes are anathema to a mature
system. So once-conforming software may be deprecated or worse. But the
programmer is still responsible for getting the machine to behave correctly.
That means programming defensively.
Making any kind of unnecessary assumptions about the platform, hardware or
compiler, is the opposite of defensive programming. Advising programmers that
they can rely up compiler to adhere to standards is to advise them that
defensive programming is unnecessary. This is "bad C advice".
> With that given, it's
> clear that Doug is making a subtle, yet valid, distinction.
No.
This distinction only applies reliably at the level of the standard, and not at
the level of the compiler. The compiler you are given is what it is.
Expecting it to be what you want it to be is to indulge in fantasy. Relying
upon that fantasy is foolish.
Now we have to rely upon most features of our tools. But we need not place
unnecessary reliance on features of the tools that are reasonably subject to
doubt. Kernigan & Pike address this in their recent book "The Practice of
Programming". They use the phrase "programming in the mainstream" as a way to
improve the reliability of software. A small quote:
"Use only those features for which the language definition is unambiguous and
well understood. Such features are more likely to be widely available and to
behave the same way everywhere. We call this the mainstream of the language."
Now, just about every C intro mentions filters of the form:
int c;
while ( (c = getchar() ) != EOF )
putchar( /*something about c */ );
Thus it is reasonable to expect this usage to fall within the "mainstream" of
C, independent of hardware, compilers, *and revisions to standards*.
But a strict reading of 7.9.7 indicates that the following is valid:
int c;
while ( (c=getchar() ) < 0 )
putchar( /* something about c */ );
But IM(NS)HO this is quite far from the "mainstream" of C. Not only because it
is a marginal interpretation of the standard, but also because it replaces a
very strong C idiom regarding character input and EOF.
------------------------------
Date: Fri, 18 Feb 2000 17:19:06 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
[EMAIL PROTECTED] wrote:
> Well in either case, I'm using C++ not C and the advice to open up the
> file in binary worked for me. But I did enjoy reading the thread
> created by my simple question.
As you can probably tell it doesn't take much of an ignition source to
light a linguistic flamewar over programming languages. At the risk of
seriously offending many readers I'll refer to W.H.G. III's quote
regarding talented programmers: they CARE about their tools.
And an intra-language dispute is often more virulent than an
inter-language dispute. Must be related to the fact that civil wars are
the most vicious wars, and family feuds are terrifying even to spectators
(e.g., domestic disputes).
------------------------------
Date: Fri, 18 Feb 2000 17:24:41 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Processor speeds.
Mok-Kong Shen wrote:
> John wrote:
> >
>
> > MHZ (I suspected) was the key. I guess I wanted a rough
> > estimate of how much faster the best home PC is as compared to
> > the latest "super-computer." I know that the gap is closing.
>
> On the other hand, a computer consiting of a huge number of
> PC-chips (like the one used for nuclear simulation) is a super-
> computer. Distributed computing in the proper sense, where
> fairly long communication paths and hence overheads are involved,
> may still be not competive in some applications. But computers
> of the afore-mentioned kind is, I believe, more cost-effective
> than computers with a few number of super-fast processors and
> can probably be more easily built and maintained and also expanded
> as the necessity arises. But there are some big computing centres
> (with the 'classical' super-computers) where such opinions are
> (understandably) more or less heresy even today.
This raises an interesting hypothesis. If loosely distributed computing
(PVM, MPI) is catching up to supercomputers I'd expect to see the
price/performance ratio of the loose collections dropping faster than
that of supercomputers. Does any reader have enough historical
price/performance info to construct a projection?
------------------------------
Date: Fri, 18 Feb 2000 17:32:41 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Keys & Passwords.
Mok-Kong Shen wrote:
> [EMAIL PROTECTED] wrote:
> >
> > This is a little off topic, but let's say I have a program that takes a
> > password and then converts that into a 256 byte array. That array is in
> > turn what's used to cipher the data.
> >
> > Does that mean the program is 2048bit encryption (256B = 2048b)? If not
> > what determines the bit level security (is it the original key or what's
> > actually used to cipher the data)?
>
> If your password has n bits then (assuming that these are random)
> you can't get more than n bits of security out of that. It is
> commonly assumed that the algorithm you use to generate sequences
> is known to the opponent. The opponent simply needs to brute
> force the n bits in the worst case. If the n bits are not (ideally)
> random, then you have less security from the very beginning.
I think the number of key bits is a red herring. The actual strength (work
factor) would be the binary logarithm of the number of possible encryption
sequences for each message. Since this is often expressed in bits the
confusion is natural.
If the suggested 2048-bit key resulted in (say) 2^200 distinct cipher texts
per plain text (or vice versa) it would have a strength of 200 bits.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Fri, 18 Feb 2000 22:15:47 GMT
[EMAIL PROTECTED] wrote:
> John Savard <[EMAIL PROTECTED]> wrote:
>
> : Zero-redundancy plaintext, on the other hand, could be encrypted
> : unbreakably even by a trivial system of encryption, since even if it
> : was easy to try all possible keys, every key would yield a possible
> : plaintext.
>
> You'd better not make the encryption *too* trivial, though.
>
> If there are less keys than there are possible decompressed files of
> a plausible length, the attacker may be able to get /some/ useful
> information -
In fact that's Shannon's distinction between
"ideal" and "perfect" secrecy. Ideal means that
the plaintext does not uniquely determine the
the ciphertext, while perfect means the ciphertext
carries zero information about the plaintext.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Brian Bosh" <[EMAIL PROTECTED]>
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 15:54:04 -0700
I have some QB code that works pretty well... It's somewhat slow (but hey, I
have it running in a loop 256^2 times), but I'm pretty sure it would speed
up in VB. Problem is that it's symmetical; and it can't be modifided to
assymetrical. This is a slightly dumbed down version, as I'm using it's big
brother for my own system.
begin ENCODE.BAS
SUB SinLineEncrypt (TE$, Key$)
' Insert you key modification code here- make sure to
' comprimise for the first 32 ASCII characters causing
' unexpected features.
' Also, make sure to somehow convert the key to
' an ASCII decimal.
FOR X = 1 TO LEN(TE$)
CurKey$ = MID$(TE$, X, 1)
CurKeyN% = ASC(CurKey$)
CurKeyN% = CurKeyN% - KeyAVG% - X
IF CurKeyN% > 255 THEN
Remainder = CurKeyN% - 255
CurKeyN% = Remainder
ELSEIF CurKeyN% < 0 THEN
CurKeyN% = 255 + CurKeyN%
END IF
CurKey$ = CHR$(CurKeyN%)
OutPut$ = OutPut$ + CurKey$
NEXT X
SinText = OutPut$
END SUB
"Khalil Haddad" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> 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: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Using virtually any cipher as public key system?
Date: Fri, 18 Feb 2000 12:58:31 -0500
>
>
> There is a distinction between using symmetric algorithms _with_
> public-key encryption and using symmetric algorithms _for_ public-key
> encryption.
>
> John Savard (teneerf <-)
> http://www.ecn.ab.ca/~jsavard/index.html
There is a distinction between public-key encryption and asymmetric
encryption. Public-key encryption is a scheme in which there is
a public key (like the one I described). Asymmetric encryption is
encryption where the encryption key is different from the decryption.
The terms must not be confused.
One other point is that Diffie-Hellman is not an encryption scheme, it
is a public key exchange, so the protocol is in fact only using symmetric
ciphers.
The scheme that I described was actually first described by ElGamal
in his crypto 84 paper. I'd suggest you go read the paper, it clearly
uses the term "public key cryptosystem" to describe the scheme.
Anton
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question about OTPs
Date: Fri, 18 Feb 2000 16:01:34 GMT
"Dr.Gunter Abend" <[EMAIL PROTECTED]> wrote, in part:
>Oh, really? If you use a home-made compression program, unknown
>to the eavesdropper, it probably will compress ineffectively, so
>that the statistical test gives a result, and if you use a
>commercially available packer, he may try all possibilities in
>order to *see* the plaintext.
Either way, it isn't good enough to let you get away with using your
OTP twice.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Question about OTPs
Date: Fri, 18 Feb 2000 22:55:40 GMT
[EMAIL PROTECTED] wrote:
> Arthur Dardia <[EMAIL PROTECTED]> wrote:
>
> : As we all know, many people are becoming interested in
> : one time pads due to their "perfect" security system.
> : Yes, while this system is perfect with totally random
> : data and a "perfectly" secure way to transfer the
> : pad-file, this is rare to come by.
>
> I don't know about that.
>
> A OTP fails against a complete known plaintext attack -
> which immediately reveals the key.
That's like saying a cat fails to be a dog.
> Even with a good source of random numbers - and a perfect
> distribution mechanism, without signing - or some better
> scrambling than XOR provides -
> I don't think the system is at all "perfectly" secure.
Right. The OTP, as described, is a privacy mechanism.
> It has about the best possible resistance to cyphertext-only attack,
> that's all.
Not so. The important property of the OTP is "perfect
secrecy", and it maintains this property regardless of the
attacker's a priori knowledge about the plaintext.
I've lost count of how many times the same dialog has
appeared on sci.crypt: one person says "perfect security"
instead of "perfect secrecy", and another objects to
"perfect".
I recommend Shannon's 1949 paper "Communication Theory of
Secrecy Systems", which is available (unfortunately as JPEGs
of scanned images) at:
http://www3.edgenet.net/dcowley/docs.html
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: EOF in cipher???
Date: 18 Feb 2000 23:11:16 GMT
>"Trevor Jackson, III" [EMAIL PROTECTED] writes:
>int C;
>while ((C = getc(fp)) != EOF) {
> /* process character in C */
>}
or Mok could write:
while(1)
{c=fgetc(fp);
if (feof(fp))
break;
etc.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: NSA Linux and the GPL
Date: Fri, 18 Feb 2000 18:27:56 -0500
> >The bigger question is why is the NSA wasting thier time with Linux? If
I
> >were them I would work on something like OpenBSD, or maybe FreeBSD since
> >OpenBSD is based in Canada. I guess the NSA is just being trendy.
>
> It *is* true that BSD is generally considered a more secure operating
> system than Linux. But Linux has improved considerably since its early
> releases.
>
> However, the NSA might have wanted the security part to be written
> from scratch, so that any known flaws in BSD would not be a problem.
> Also, Linux is ahead of BSD in another area: it is more
> POSIX-compliant.
>
> Whatever else one makes of the news item, I think it is a feather in
> Linux' cap.
I wasn't trying to start a "my os is better than yours" thread. I meant, if
the NSA was striving for security they should go with something that is more
secure than Linux. I am not sure if you know much about OpenBSD but, the
OpenBSD source code has been audited several times and most of the work they
do is with security in mind. I see Linux being developed as a feature rich
UNIX like operating system, and security comes somewhere after that. As for
flaws in the BSD code, if they are going to correct all the security
concerns in Linux, I don't see why they could not do the same for BSD. I
think they would have less work on thier hands if they went with OpenBSD.
Also BSDes are licensed with the BSD license, which means you can do pretty
much anything you want as long as you give the authors of the code you
modify credit. So the concerns about the GPL license wouldn't be a problem.
Or maybe the NSA should just start from the ground up and come out with
NSAOS. And release it to the public with all sorts of backdoors! :)
- Adam Durana
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 15:24:16 -0000
"Paul Bais" <[EMAIL PROTECTED]> wrote in message
news:88jelj$lb7$[EMAIL PROTECTED]...
> Hi
> I'm looking for a crypt() function in VB as well. In fact,
I want to encrypt
> user passwords for use on unix machines. Does anyone have
the source in C or
> VB?
I don't have actual possession of one, but all you should
need to do is get ahold of the crypt() function that you're
UNIX system uses. If you use Linux or some other open source
system it shouldn't be difficult.
Joe
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Using virtually any cipher as public key system?
Date: Fri, 18 Feb 2000 16:32:01 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote, in part:
>The scheme that I described was actually first described by ElGamal
>in his crypto 84 paper. I'd suggest you go read the paper, it clearly
>uses the term "public key cryptosystem" to describe the scheme.
Of course it's public key encryption. Because Diffie-Hellman is used.
But it isn't a way to perform public-key encryption using only DES and
similar methods.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: NIST publishes AES source code on web
Date: Fri, 18 Feb 2000 23:40:21 +0000
February 18, 2000:
"The AES finalist algorithm source code is being made available under
the 'Technology and software - unrestricted' (TSU) license exception
of §740.13 of the updated Export Administration Regulations (EAR) of
January 14, 2000."
-- http://csrc.nist.gov/encryption/aes/round2/r2algs-code.html
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: VB & Crypto
Date: Fri, 18 Feb 2000 17:22:51 +0100
"Peter Rabbit" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
-cut-
> I do not agree that VB is too slow. It all depends what you try to
> accomplish. I've written encryption software in VB6 that does ~1 Meg per
> second using 6 rounds of XOR and BitRotation in a stream cipher algo.
> The slowest part, when writing in VB, is the conversion from STRING to
> NUMERICAL but that is because most VB programmers don't know about
> StrConv() which is very fast. Granted, C/C++ is probably faster, but
> don't knock VB. For working on, and testing your algo on the fly VB is
> hard to beat.
> Peter Rabbit
Yes, it depends on what kind of speed you need. I've had to implement an
encryption algorithm in VB, and it was not fun at all. The language lacks
most of the operations that crypto.algo.writers like. And if that doesn't
put you off, the runtime overflow checking etc. will be next.
So, I find researching bitwise-intensive things in VB to be a pain; There
are too many things you have to work around.
As a side note I use C, C++, Delphi, and assembler regularly. It all depends
on what you need. And what I usually need is real time performance, so I
don't use Windows, and VB cannot compile for non-Windows targets. So I don't
use VB.
--
/Kasper Pedersen
[PGP 0xCAF1E27C, 49B0 F0F1 2A6E AEE8 4AAA 8672 D4B9 5F58 CAF1 E27C]
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 16:54:13 -0700
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > > > > while ((C = getc(fp)) != EOF)
>
> [ ... ]
>
> > > Unfortunately, the above code will run on many systems without
> > > problems until fp is a binary file which happends to contain
> > > the code 0xff, which is equal to (signed char)-1 (on machines
> > > with 8 bits for a character).
> >
> > Only if the C library (presumably it came with the compiler)
> > is implemented incorrectly.
>
> Not so -- if "C" in the code above is defined as a char instead of an
> int, there WILL be a problem. If, for example, char is signed by
> default, C could contain -1 due either to reading 0xff from the file,
> OR encountering EOF.
I suppose you snipped Trevor's statement that C needs to be an
int because you didn't notice it? Perhaps Runu, although he was
replying to Trevor, didn't notice it either?
John M.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: EOF in cipher???
Date: Fri, 18 Feb 2000 16:56:59 -0700
Johnny Bravo wrote:
>
> On Fri, 18 Feb 2000 10:28:00 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >The issue is the type of the variable C. To operate correctly it must
> >be an int not a char.
>
> Unsigned char works if your compiler can handle it, ANSI C.
Wrong.
The point is that C must be able to hold every byte value
*plus* EOF - 257 different numbers. (The return from getc()
is assigned to C, which can convert the result if C is not
an int, and *then* C is compared to EOF).
John M.
------------------------------
** 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
******************************
