The next step in going against "conventional wisdom" - Create your own Crypto!

[Vessko]

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.

[CIYAM]

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.

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!

[The Chainmaker]

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

[2112]

recording it on CD-ROMs

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

[Flashman]

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.

[hhanh00]

Good points - I am not inventing a new type of cypher.

The idea of a OTP is at least hundreds of years old.

The only idea I would ask anyone to accept is that "secure hashes are secure" (as many other crypto algos work upon that assumption I don't think I have violated any sacrosanct idea).

If SHA256 is not secure then Bitcoin should have already been destroyed (and that is the OTP method that I use).

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.

[CIYAM]

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.

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).

[hhanh00]

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.

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 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.

[CIYAM]

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.

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).

[hhanh00]

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

[jonald_fyookball]

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.

[CIYAM]

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).

[hhanh00]

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

[CIYAM]

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

Any suggestion for a better title?

[jonald_fyookball]

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).

namecoin?

[CIYAM]

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).

namecoin?

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).

[Soros Shorts]

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.

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.

[CIYAM]

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 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).