Well, if we're talking about real crypto and not the pass-notes-to-girlfriend type I'd prefer to publish it in a scientific venue first rather then do the reveal on GOG :)

Anyway, I thought I'd drop this here, a very interesting read.

The actual (upcoming) paper: https://arxiv.org/abs/1610.06918

And a lighter take on it by Ars Technica: http://arstechnica.com/information-technology/2016/10/google-ai-neural-network-cryptography/

Is this the sequel to ransomware developer seeks help from security expert?

I love these so-called cybersecurity news articles. It is true that many ransomware (and malware in general) is so poorly written that the programmer in charge cannot even make a few coherent calls to standard Windows crypto APIs :) I would guess it doesn't take a security "expert" (a word reserved for a handful of people imho) to fix that.

Either works. Although the days of doing things by hand is generally not done much; not that done by hand is less secure when you have random data to encrypt with (OTP).

What's secure today is now more determined by how long before it would be broke with today's tech, and then in the tech in 5-10 years. 1024bit RSA keys were secure back late 90's but they upgraded to 2048bit keys not that long ago. DES 56 bit keys were relatively secure up to the mid 90's, but is woefully inadequate today.

A new useful crypto could just be a combination of crypto. not only the crypto then has to be known and the combination but the offset, and the keys.


Currently I am working on a crypto that uses a 72 byte block. I'm thinking of submitting it for testing, so we'll see how that goes.

I doubt single pass DES was ever rolled out with security as the primary goal :) But let's not drift into conspiracy theories...

I disagree with this. Cryptanalysis hardly relies on technology, as demonstrated by the practical security of AES today (the many purely academic attacks on weak variations are irrelevant to us here). DES and RSA had theoretical shortcomings which lead to the attacks in the first place, which were in turn made feasible by the advancing tech, no?

As i understand it. DES originally had a 64bit key space. However the NSA demanded he weaken it so they could break it if they had to. I think it was the NSA could brute force all the keys in a day at 56 bits, back in the 90's.

If in 5 years computers are 10,000x stronger than they are today, not including hardware-specific brute forcing, then it doesn't matter how secure something is, the limited keyspace can still be brute-forced faster. Not to mention NSA and other large groups will have thousands of computers all working in parallel to break keys.

Although weaknesses in encryption are preferred and brute forcing is the last resort, it doesn't change it much. The 8bit computers were 3Mhz, we are now having multi-core 4Ghz processors, in only the span of a few decades. If they can't boost the speed they will keep adding cores. But it won't be too long before they drop Silicon for a better material.

Well just for fun here's some cipher I just made (in about 3 minutes), loosely based on OTP and Enigma, for simplicity I call it Renigma.

[code]
void renigma(char[] enc, ref Random gen) {
ubyte[26] recode;

foreach(i; iota(0, 26))
recode[i]=i & 0xff;

foreach(ref c; enc)
if (c >= 'A' && c <= 'Z') {
randomShuffle(recode[], gen);

c = cast(char) (recode[c - 'A'] + 'A');
}
}
[/code]

Throwing in a seed/key of 100, I've encrypted the following message. I've also confirmed it will decrypt (assuming you reverse the table using the same seed). A downside is it only works on a per-buffer basis (in this case, per line). So...

LQWJ TT IX MJSYWTG NHL UISHOCD, YF YEM ZQC YDQY MHXV AWA JUYZ SCFIJIJEK.
REDE MOSJ RVEP WWHCUJ OYYKKVINO WIZRLZWYT LK WM'C NFZLFSTM FWSRXPJFD.

It wouldn't be hard at all to modify it for a longer range of characters, for uppercase/lowercase, or doing quite a bit more. Still I wouldn't call it particularly secure, secure enough for casual encryption vs family friends and for your company and boss, or sending messages to a lover.

Questions about the cipher? ideas?
How would you improve it?

Let's get a discussion on... maybe?

Just experimenting with Crypto. The results are interesting, re-arranging and re-encrypting and how many times before patterns disappear from not being affected by other areas. I'm talking about blocksizes far above 4 and 8, maybe 110 block-sizes, or even larger. The largest blocksize I might consider is 65,280 (just under 64k), though how many passes it would need I'm not sure. Probably 30 as a guess.

Here is some sample test output/concept test, still working on my new cipher a bit, wondering if I should make it have a new 16bit cipher on every pass (which makes it larger and a bit more secure).

To note, the input source is all 0's, except for the byte (2 hexes) which is changed from 0 to 16.