karn@faline.UUCP (05/15/87)
In article <1615@Umunhum.STANFORD.EDU>, paulf@Umunhum.UUCP writes: > 4) Design a piplined serial encryptor / decriptor pair using LFSR's. > This is probably stretching part 97 a bit. > > A STA for LFSR encryptors would be nice for those who want closed systems; > the situation is similar to PL - type access on a closed repeater. I wish you hadn't brought this up. Linear Feedback Shift Registers (LFSRs) are already in use in the K9NG and WA4DSY amateur packet radio modems as data randomizers. They're called "scramblers" in the commercial world, but this word has bad connotations in the amateur world. The purpose of a scrambler or randomizer is NOT to hide the data being sent, but rather to change its statistics to improve the modem's performance and to reduce co-channel interference. In particular, scrambling gets rid of the DC component in a long flag stream, and it guarantees plenty of data transitions for clock recovery in the event you're not running HDLC and you're sending long strings of 1's or 0's. In part 97 wording, the purpose here is to facilitate communications, not hide the meaning. You need to know the polynomial (the taps on the shift register) being used in order to decode a randomized data stream. Steve and Dale have published their polynomials, so as far as I'm concerned they aren't encrypting. However, this wouldn't be much of an encryption system even if they tried to keep their polynomial secret. All you need is 2N bits of the pseudo-random sequence generated by the LFSR (where N is the number of stages in the shift register) and you can obtain the polynomial by solving a simple linear system of equations. Shift register feedback systems intended for encryption must use NON-linear feedback. The effect of this is to simulate a LFSR with an extremely long register, so long that the attack just mentioned isn't practical. Based on the available public information about the secret NSA algorithms now being recommended for the replacement of DES I think it's a good bet that they're based on nonlinear feedback shift registers. I say this because they're stream ciphers and they run much faster than DES in hardware. NSA also claims that you have to get your keys from them in order to guarantee security (!) because constructing a "good" key requires special knowledge of the algorithm. All this is consistent with the nature of non-linear feedback shift register algorithms. Phil
verber@osu-eddie.UUCP (Mark A. Verber) (05/19/87)
It would seem to me that a public key crypto-system would be perfect for this kind of application. You could query the machine for its public key, encrypt your password using that key and then transmit your encrypted password. The machine which you are trying to access then decodes your password with it's private key and verifies login. The primary problem with using a public key system is selecting which method to use. The best method is RSA, but RSA is patented and cost mega bucks. Knapsack could be used, but it has been broken. This might not be too much of a problem though since super secure communications is not needed, it would be on packet radio if security was important. Cheers, ----------------------------------------------------------------------- Computer Science Department Mark A. Verber The Ohio State University verber@ohio-state.arpa +1 (614) 292-7344 cbosgd!osu-eddie!verber
pdb@sei.cmu.edu (Patrick Barron) (05/20/87)
In article <3569@osu-eddie.UUCP> verber@osu-eddie.UUCP (Mark A. Verber) writes: >It would seem to me that a public key crypto-system would be perfect >for this kind of application. You could query the machine for its >public key, encrypt your password using that key and then transmit >your encrypted password. The machine which you are trying to access >then decodes your password with it's private key and verifies login. Two problems with this: 1) You're still encrypting things. It's illegal to send encrypted messages (of any kind) over the Amateur Radio Service. 2) If the machine only has it's private key and a single public key, what's to stop the Bad Guy from listening to what my password looks like when transmitted back to the system, and just using that? --Pat.
andersa@kuling.UUCP (Anders Andersson) (05/22/87)
In article <3569@osu-eddie.UUCP> verber@osu-eddie.UUCP (Mark A. Verber) writes: >It would seem to me that a public key crypto-system would be perfect >for this kind of application. You could query the machine for its >public key, encrypt your password using that key and then transmit >your encrypted password. The machine which you are trying to access >then decodes your password with it's private key and verifies login. I agree with the choice of method, but is it enough to encrypt just the password? Packet radio connections seem to be perfect targets for active intrusion (directed towards the host computer as well as the user's terminal) just as well as passive "wireless-tapping". Why bothering with finding the password, when it's possible to achieve synchronization with the real packets and suddenly take part in the conversation, giving malicious commands to the host? Of course the legitimate user will notice that something weird is going on, but it might be too late - and the faked terminal could act as a faked host at the same time, maybe misleading both ends during the whole operation. Is this a possible scenario, or have I overlooked something? My personal experience with packet radio is still minimal, least to say. If I were to solve the above problem, I would consider using the authentication functionality of public key encryption, which would make for certain (sort of) who's talking to who. I would still have the problem of identifying the source of the public key which I first received, though... Encrypting the password only is still a worthwhile thing to do, if the password itself is something you want to protect, and not just your packet connection (maybe you have both wired and packet connections to the same host, but use packet relatively seldom). Note that the intruder can simply save your encrypted password (and any other encrypted stuff) for later use in a faked session, where he can replace the plaintext part with whatever he wants, unless the key varies between sessions. Just to complicate things, the Swedish PTT doesn't allow encrypted data to be sent over amateur radio, but maybe they'll be able to make an exception for digital communications... Anyway, I do agree with you that the amateur nature of packet radio might perhaps not warrant such a high level of security. This is SM5POR - or at least I've made you believe that! :-) -- Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden Phone: +46 18 183170 UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)
galvin@udel.UUCP (06/10/87)
In article <1370@aw.sei.cmu.edu> pdb@sei.cmu.edu.UUCP (Pat Barron) writes: >In article <3569@osu-eddie.UUCP> verber@osu-eddie.UUCP (Mark A. Verber) writes: >>It would seem to me that a public key crypto-system would be perfect >>for this kind of application. You could query the machine for its >>public key, encrypt your password using that key and then transmit >>your encrypted password. >Two problems with this: >2) If the machine only has it's private key and a single public key, what's > to stop the Bad Guy from listening to what my password looks like when > transmitted back to the system, and just using that? This is easily corrected with a "nonce identifier". You are missing the more fundamental problem of an active eavesdropper who simple substitutes his/her favorite public key. Jim ARPA: galvin@udel.edu BITNET: galvin@udel.edu CSNET: galvin%udel.edu@csnet-relay UUCP: ...!ihnp4!seismo -\ ...!allegra!seismo -->!galvin@udel.edu ...!harvard -/ -- James M Galvin