111–120 of 409 posts
Earlier quoted context omitted.
Aren't all undocumented instructions / opcodes actually UB? If you execute an undocumented instruction the processor has to do something.
You can't really accidentally or unintentionally arrive at undefined behaviour in assembly language though. You would have to explicitly use an undocumented instruction or opcode and the result would probably be a hardware interrupt or exception every time.
Earlier quoted context omitted.
There is a difference between rolling your own crypto and rolling your own crypto. There is Monocypher, then there is this company that is trying to do some weird protocol using CRC, DES in CBC mode and MD5. The sentence was targeting the latter case.
No, it is targeting both. I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, I haven't looked to see if there is any sensitive memory scrubbing. Of the bugs listed most are performance bugs by someone who doesn't know C very well yet have they done the things actually!my required in a crypto library like attempting to make sure all branches are the same instruction…
He actually talked about avoiding side-channel attacks in his two previous articles about Chacha20 and Poly1305.
Earlier quoted context omitted.
C adds a layer between your code and the system. It abstracts away memory layout, locations, as well as function call semantics, and a many other things. For example, given a C program, you will not be able to tell me with certainty that a variable will occupy memory on the stack, any of your particular processor registers, etc. Formally, C is a language to control the C Abstract Machine , as described in the standar…
Rust doesn't even exist on a plethora of platforms which C targets. I have high hopes with D and give or take ~2 years, it'll be able to progress forward in lots of domains. Not sure about other languages.
First let me say that I've followed your work a bit and I'm really impressed with the library. I'm currently planning on rolling my own crypto as well and your library is on my list of the things to look at. One question: > I was shifting a uint8_t, 24 bits to the left. I failed to realise that integer promotion means this unsigned byte would be converted to a signed integer, and overflow if the byte exceeded 127. Th…
There's no sign-extension involved. Let's say the input is (uint8_t)128. This gets promoted to (int)128, which is then shifted 24 bits to the left. If the input was (int8_t)128, it would get sign-extended into (int)-128, but that is not the case here. With 32-bit ints, this operation will result in 0x80000000, shifting a bit into the sign bit, which constitutes an overflow (and undefined behavior). Think about it in…
u64 = u8 Here the integer promotion might transform u8 into a 16-bit or 32-bit int (depending on the arch). Which will then be converted to a u64 AFTER the shift. Which might have you lose half or more of the bits.
His code is not that though, it's
u32 = u8 which should work only if ints are 32-bit on the system you compile on.
Is there also any plain to implement scrypt (based on the salsa), SPHINCS (uses BLAKE(1) and Chacha), Ed448-Goldilocks, Keccak or any of the CAESAR candidates? (The ones that seemed the most interesting to me were NORX, Keyak (based on keccak) and HS1-SIV (based on chacha)).
It was a fun read, except when all the C bugs were listed. It's getting tiresome to hear about folks writing nominally Important software in a language where it is extraordinarily difficult to get things absolutely correct, with paltry excuses such as "it needs to be fast" or "it needs to be portable [0] to a VAX-11/750." It doesn't give me confidence that these completely usual bugs popped up early on, and it will n…
Are there any practical alternatives when that kind of portability is needed?
What about transpiling to C? I know Haskell and OCaml can be made to compile their code into C code that you can then pass on to a C compiler.
Earlier quoted context omitted.
Rust doesn't even exist on a plethora of platforms which C targets. I have high hopes with D and give or take ~2 years, it'll be able to progress forward in lots of domains. Not sure about other languages.
Any language that needs evangelists is clearly not able to progress on its own merits and archievments.
Earlier quoted context omitted.
Yeah and imagine the kind of exciting bugs that exist in new and immature libraries! :)
Yes, but are hackers going after common used libraries to get more vulnerable systems to attack or are they going to spend time on some unknown homebuilt crypto? In some cases, security through obscurity works well in practice.
Earlier quoted context omitted.
Even just using crypto primitives is dangerous unless you've got experience. There's an old post from matasano about it https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...
Every line of code written can be a severe vulnerability, not just code dealing with crypto. In case of crypto, being well-informed is good enough to not mess up those kind of implementations (on a theoretical level). The problems mentioned can be pointed out and verified on paper. But you can't say the same thing for code.
Earlier quoted context omitted.
There's no sign-extension involved. Let's say the input is (uint8_t)128. This gets promoted to (int)128, which is then shifted 24 bits to the left. If the input was (int8_t)128, it would get sign-extended into (int)-128, but that is not the case here. With 32-bit ints, this operation will result in 0x80000000, shifting a bit into the sign bit, which constitutes an overflow (and undefined behavior). Think about it in…
right, but he only used unsigned types. I think there is another problem here: u64 = u8 Here the integer promotion might transform u8 into a 16-bit or 32-bit int (depending on the arch). Which will then be converted to a u64 AFTER the shift. Which might have you lose half or more of the bits. His code is not that though, it's u32 = u8 which should work only if ints are 32-bit on the system you compile on.