The Winds of Change - The Three Snake Oils of Cryptography.
in [Cryptography]
|
Prev: The Winds of Change - The Three Faces of Cryptography.
Next: General factoring result for k^m = q mod N
From: Bruce Stephens on 14 Jun 2010 15:40 adacrypt <austin.obyrne(a)hotmail.com> writes: [...] > I am totally averse to working in binary and cannot see any advantage > - ok I know that everything in computing starts and finishes as > machine code that of course is modelled in binary but at the user > interface there is no gain in this - Think data, not programs. > you guys are hooked on binary but there is nothing to be gained by > typing in files in raw binary - better to read in the files character > by character and let the computer change it to binary - it is much > better at doing this than than any human being - I've no idea what you're trying to say. It sounds like you're an idiot. What we meant was that you should assume that whatever the user wants to encrypt is already a file on the computer and that you should encrypt that. Similarly, assume that the encrypted data to be decrypted is a file. How the files are produced is none of your business. > there are many things that have become entrenched practice in recent > years in the crypto industry but that does not mean they are here to > stay. Don't hold your breath for them to change. > There's been a lot about newline instigation - whether it's plaintext, > ciphertext or whatever, the line length in Ada is simply the number of > characters called for by the command line (Set_Line_Length) and then > bingo ! a new line is born.- can't see what the fuss is about. You don't want to be able to encrypt even text accurately? [...]
From: Bryan on 14 Jun 2010 16:26 rossum wrote: > adacrypt wrote: > >I can easily encrypt anything from 00 to FF > > Then please amend your program so that it does so. No, no, absolutely not. The best features of Adacrypt are the ones that ensure no one will use it. -- --Bryan
From: Gordon Burditt on 14 Jun 2010 17:29 >I had better make it clear that I am only interested in security of >information All of the file formats I have mentioned can contain information. They can contain information that governments will (literally) kill for (Think about what spies steal, wiretaps, hidden cameras, spy satellites, etc.) >- secure information interchange a la ASCII <=> code for >information interchange - I am quite satisfied that I can secure any >other form of data if I try but there is no need yet for that ? ? - Writing code to be character-set-independent may be simpler than dealing with disallowed characters. If you design a house, you're not going to put in a toilet until YOU personally need to pee, no matter how much other household members complain? Have you ever lived around a high-school English teacher? If you send her a message, it better be spelled correctly. If you submit a paper, it better not have one spelling error or you get an F. Arbitrary newline insertions don't leave spelling intact. >my present ciphers are very speedy and easily managed - 15000 >charcters per second on a home computer is ok for now at least - I >guess I'll just stick with that for now - adacrypt That's pretty slow compared to most networks, but if you just use it for email (to yourself), it's probably acceptable to have even 300 bits/sec modem speeds. The input character set for a cipher is not a "management issue". It's a fundamental design issue for a cipher. Encryption intended for a cable box to protect the cable company from the customer isn't suitable for encrypting emails.
From: adacrypt on 15 Jun 2010 03:33 On Jun 14, 6:44 pm, rossum <rossu...(a)coldmail.com> wrote: > On Mon, 14 Jun 2010 07:36:15 -0700 (PDT), adacrypt > > <austin.oby...(a)hotmail.com> wrote: > >you are way off the mark in talking 00 to FF > > You are way off the mark in talking ' ' to '~', all you need is to > encrypt two characters: '0' and '1' - the users can type in their > files in raw binary. > > rossum Hi again, After a moment's thought I realise there is no problem with images or indeed entire websites - these have been created within the bounds of writable ASCII - they are therefore imminently encryptable by my vector cryptography - I remember making a note of these before during a web design session but forgot about since then - even groups of individual pixels (hypothetical extreme - let the boo boys note) may also be enciphered by encrypting their colour codes. - adacrypt
From: Bruce Stephens on 15 Jun 2010 03:53
adacrypt <austin.obyrne(a)hotmail.com> writes: [...] > After a moment's thought I realise there is no problem with images or > indeed entire websites - these have been created within the bounds of > writable ASCII - they are therefore imminently encryptable by my > vector cryptography - I remember making a note of these before during > a web design session but forgot about since then - even groups of > individual pixels (hypothetical extreme - let the boo boys note) may > also be enciphered by encrypting their colour codes. - adacrypt I suggest you take a few more moments to think. It's possible to convert binary to ASCII. That's done routinely (common examples are uuencode, base64, yenc). There's a cost to that, however. And in this case there's no point: just handle binary. |