Topic: The next step in going against "conventional wisdom" - Create your own Crypto! (Read 1731 times)

That is indeed something that should be considered and yes the CA component of HTTPS is IMO the biggest part of the problem with it.

To be clearer the reason that I am envisioning something quite different to HTTPS is that I see blockchains (note not singular) and P2P as being the two key core technologies of the internet of the future (and HTTPS was really designed for a traditional client/server model).

Maybe you could look into improving HTTPS before thinking about replacing it completely? For instance, if your problem with HTTPS is its reliance on trusted Certificate Authorities then look into replacing that piece with some kind of P2P system. I doubt many people would have any issues with HTTPS over TLS 1.2 and the rich cryptographic suites that it supports.

That project has mostly failed because it just replaced one name squatting system with another (I don't like the idea of anything like DNS).

namecoin?

Any suggestion for a better title?

To me it sounds like the title is "The next step in going against "conventional wisdom" - Create your own rocket!

I think perhaps the title of this topic has confused people as I didn't intend it to mean creating things like the lowest level algos but instead the idea of replacing conventional implementations such as HTTPS in particular.

The comparison with the other topic is more to do with challenging "conventional wisdom" (i.e. that you *can't create a replacement for securely encrypting data* for something like HTTPS) so it is the system implementation rather than its low level algorithmic parts that are key.

The main interest I have is in how we create a new secure internet that doesn't use DNS or HTTPS (this topic being about the latter of these two things).

I think the two (brain wallet and crypto) are very different.

I know almost nothing about cryptography, but I know it's complicated enough that there's no point for me to try to roll my own.  And those that know quite a bit more than me are saying that it is quite a deep subject.

Comparatively, brain wallets seem much simpler.  There are really only a few known principles that must be followed, and those principles are easily understood.  Cryptography is a complete science with a large body of knowledge.  It's much more complex and mysterious.

Well - then the receiver has to carry a database of nonces with him wherever he wants to be able to decrypt a message. Otherwise, you just described a stream cipher - it's definitively not a new crypto

Edit: http://en.wikipedia.org/wiki/Stream_cipher

For sure a nonce cannot be re-used - so in a P2P situation each client would make sure it does not allow nonce re-use to occur so this is easily prevented (it just requires storage space for old nonces which could perhaps be reduced by prefixing nonces with say a date to allow for the later removal of old nonces).

This looks fairly subject to chosen ciphertext attacks. The nonce has to be sent with the encrypted message. I craft a new message with the same nonce and modify the body of the cipher text. Since I know they are XORs, I can change the decoded content or retrieve the message little by little by sending several attempts and seeing how the receiver reacts.

Okay - these are very good points and it is not a "true OTP" at all (for the obvious reason you pointed out) but is instead a PRNG key stretcher (starting with a shared secret). In order to never re-use the same "pseudo OTP" (is that term acceptable?) a message nonce is combined with the shared secret (the nonce itself would be sourced from /dev/random or equivalent).

Of course the "shared secret" could also be determined using ECDSA key pairs (as an alternate to using GPG or some other method of communicating the shared secret).

This raises a lot of red flags. OTP is used as an example of perfect secrecy cipher. Mainly to introduce the more advanced concepts because it only works if the pad is perfectly random, used once and as long as the text to encrypt. All of which makes it impractical. I don't know how you produce your OTP but anything short of the previous is not a OTP.
"secure hash are secure" have to be framed in a particular context. What is the attack model? CPA, CCA, RO, etc. I could go on and on but the point is that these sentences don't give much confidence to start with.

Well a CDR you could overburn to wipe. Or shred.

IF you had a BDROM fully filled with randomness and emailed like a fiend all day, managing about a megabyte of ascii output daily, I think it would take you about 70 years to use it all.

Actually CD-RWs. Using erasable media is a great protection against accidental reuse, one of the most important failure modes of the OTP.

most people have a hard time getting a wallet open.  not going to be any creating a crypto for them

Strange that you'd bother typing it then (and why are you so keen to become the teacher to someone who you are are so keen to insult?).

If you haven't gathered what the purpose of this topic is (and the previous one linked to in the OP) then that isn't my problem.

Enjoy venting!

I don't really care whether you'll read it. From what I've seen from you so far, you are unlikely to learn from it anyway.

Consider it just a "cry of the soul" when somebody needs to vent his frustration at some idiocy, even knowing that it isn't going to change anything.

If you really want someone to actually read a very long reply (which presumably you must have wasted quite a bit of time typing) then next time I'd suggest not starting it with that.

Maybe because you are an ignoramus without a clue?


False. Wrong generalization using the word "any". Demonstrate to me how Blowfish has been influenced by the NSA.


Certainly. Go ahead and discuss. Maybe you'll learn something. Just don't ask others to rely on any cyphers you have created.


Some of us are more qualified than others. Many of us are more qualified than you. But there is nothing wrong in discussing things.


OK. Let's. As you undoubtedly know, it is unbreakable in theory. Explain to us why it is totally unusable in practice. Emphasize the various possible protocol pitfalls. Describe the key exchange problem.


No, it is not. It is actually one of the worst encryption methods in existence. It is just the most resistant one to cryptanalysis.


Wrong. It relies on the two sides having a key as long as the total length of their communication (over all the time they will be communicating), which key is totally, unpredictably, physically random. How would the sides know beforehand how long their communication would be? And, if they don't, how would they exchange a key with such a length? And, if they can do that in a secure way, why not exchange the message itself?

Some practical implementations have involved giving special "pads" (notebooks) with the key to the soldiers during WWII, although I have no information regarding how the key was created. More contemporary example includes generating the keys from the noise of radioactive decay (the closest thing to random we have in nature), recording it on CD-ROMs and delivering them to the embassies with diplomatic mail. Of course, this relies that the key will not be intercepted and that it will be indeed random, which we cannot theoretically guarantee.


At this point you have already trusted 3rd-party software to generate the keys and perform key exchange. Why not also trust it with the encryption? And, if it is untrustworthy to begin with, your communication is already compromised (the attacker has the key), no matter what software you use for encryption.


From what you have demonstrated so far, your incompetence in cryptology is orders of magnitude larger.


Wrong conclusion. Revealing that SHA-256 is not secure might cost more than one is able to gain by "breaking" Bitcoin.


You use SHA-256 to generate the key and call this a "one time pad"? Either I did not understand what you wrote, or you are a complete moron.


/var/random is not mathemathically random. The output is hashed in an attempt to increase randomness - because this is the best we can do. The result is still not theoretically random - we just hope that it is random enough.


Nobody is stopping anyone from "questioning about crypto". We are just trying to stop ignorant morons from making idiotic statements about crypto that we would have to waste time debunking, like I am doing right now. If you want to learn and have legitimate questions - ask away. If you are going to bombard us with silly ideas and conspiracy theories exposing you ignorance - fuck off.


Uh-huh, and you genius were able to figure it our and are in a position to reveal it to the world. /facepalm


Actually, XTS sucks even for physical disks; it is just the best we can do there, since we are limited by the disk geometry. A disk sector of 512 bytes still has to be encrypted into 512 bytes - you don't have additional space for initialization vectors and authentication codes and checksums. (And, no, you can't rely on compression shrinking the size of the stuff you are going to encrypt.)


The NSA has had huge influence on crypto. They took IBM's Lucifer and changed it into DES, in practice strengthening it against an attack that wasn't known to the civilian sector at the time. They have also weakened a random number generator suggested by NIST - this is documented fact. They have also proposed particular elliptic curves suggested by NIST, except that now nobody knows the reason why - was it in order to strengthen or to weaken the encryption?


This is because the ignorance you have demonstrated so far in cryptology makes us totally uninterested in your algorithm.


And you trust OpenSSL exactly why? And how do you know that you haven't introduced any weaknesses in your wrapper?


OK, explain us exactly what the NSA did, according to Wikileaks. (Given that you got even the source of the information wrong, I am willing to bet that you don't know what the information is, either, let alone understand its implications.)