Crypto++ through 8.4 contains a timing side channel in ECDSA signature generation. Function FixedSizeAllocatorWithCleanup could write to memory outside of the allocation if the allocated memory was not 16-byte aligned. NOTE: this issue exists because the CVE-2019-14318 fix was intentionally removed for functionality reasons.
@dwmcrobb discovered a latent bug in `FixedSizeSecBlock`. It was reported at [GH #988](https://github.com/weidai11/cryptopp/issues/988). In the 988 bug we fixed the pointer problem and cleaned up the class.

Since the `FixedSizeSecBlock` overhaul we started seeing failures on AppVeyor, which tests the Windows gear. For example, see [Noloader | Crypto++ | Win32](https://ci.appveyor.com/project/noloader/cryptopp/builds/36993303/job/nonj2m75fgy21gyr). (Win64 is OK).

The problem appears to be too many asserts. I've seen this before on AppVeyor. A few intermittent asserts are OK, but a stream of them causes a failure. The asserts that are firing are alignment related in [ByteReverse](https://github.com/weidai11/cryptopp/blob/master/misc.h#L2207) and [IteratedHash](https://github.com/weidai11/cryptopp/blob/master/iterhash.h#L154):

```
// misc.h
template <class T>
void ByteReverse(T *out, const T *in, size_t byteCount)
{
    // Alignment check due to Issues 690
    CRYPTOPP_ASSERT(byteCount % sizeof(T) == 0);
    CRYPTOPP_ASSERT(IsAligned<T>(in));
    CRYPTOPP_ASSERT(IsAligned<T>(out));

    size_t count = byteCount/sizeof(T);
    for (size_t i=0; i<count; i++)
        out[i] = ByteReverse(in[i]);
}
```

And:

```
// iterhash.h
inline void CorrectEndianess(HashWordType *out, const HashWordType *in, size_t byteCount)
{
    CRYPTOPP_ASSERT(in != NULLPTR);
    CRYPTOPP_ASSERT(out != NULLPTR);
    CRYPTOPP_ASSERT(IsAligned<T_HashWordType>(in));
    CRYPTOPP_ASSERT(IsAligned<T_HashWordType>(out));

    ConditionalByteReverse(T_Endianness::ToEnum(), out, in, byteCount);
}
```

Tracing things back, it looks like `GetAlignmentOf<T>` is going a bit sideways. For example, for `word64` array, the compiler lays out an array aligned on 4 bytes (recall this is a 32-bit problem). However, `GetAlignmentOf<T>` is returning 8 because of `__alignof(T)` from [misc.h](https://github.com/weidai11/cryptopp/blob/master/misc.h#L1178):

```
// misc.h
template <class T>
inline unsigned int GetAlignmentOf()
{
#if defined(CRYPTOPP_CXX11_ALIGNOF)
	return alignof(T);
#elif (_MSC_VER >= 1300)
	return __alignof(T);
#elif defined(__GNUC__)
	return __alignof__(T);
#elif defined(__SUNPRO_CC)
	return __alignof__(T);
#elif defined(__IBM_ALIGNOF__)
	return __alignof__(T);
#elif CRYPTOPP_BOOL_SLOW_WORD64
	return UnsignedMin(4U, sizeof(T));
#else
	return sizeof(T);
#endif
}
```

`GetAlignmentOf<word64>` returns 8. I think this is actually just a symptom. I _think_ the real problem is `IsAligned<T>` from [misc.h](https://github.com/weidai11/cryptopp/blob/master/misc.h#L1219):

```
// misc.h
template <class T>
inline bool IsAligned(const void *ptr)
{
	return IsAlignedOn(ptr, GetAlignmentOf<T>());
}
```

Notice the function calls accepts a pointer and calls `GetAlignmentOf<T>`, and not the pointer-to-T `GetAlignmentOf<T*>`. Switching to a pointer-to-T with `GetAlignmentOf<T*>` clears the asserts. This makes sense since a pointer only needs to be aligned to 32-bits on a 32-bit platform. And on 64-bits, pointers are 64-bits which coincides with the `sizeof(word64)`, so everything is OK.

I also noticed the same behavior on 32-bit Linux. Those same asserts are firing, so it is not a Windows-specific problem.

My question is, why are we using `GetAlignmentOf<T>` instead of the pointer-to-T `GetAlignmentOf<T*>`? What insight did Wei have, or what was Wei trying to achieve by increasing alignment requirements for 64-bit words?

I _think_ we should change it to pointer-to-T `GetAlignmentOf<T*>` for this test.

@mouse07410, any thoughts?

AppVeyor failures after fixing FixedSizeSecBlock
This is a GitHub Issue
repo:cryptopp
owner:weidai11
Title : AppVeyor failures after fixing FixedSizeSecBlock
Issue date:

--- start body ---
@dwmcrobb discovered a latent bug in `FixedSizeSecBlock`. It was reported at [GH #988](https://github.com/weidai11/cryptopp/issues/988). In the 988 bug we fixed the pointer problem and cleaned up the class.

Since the `FixedSizeSecBlock` overhaul we started seeing failures on AppVeyor, which tests the Windows gear. For example, see [Noloader | Crypto++ | Win32](https://ci.appveyor.com/project/noloader/cryptopp/builds/36993303/job/nonj2m75fgy21gyr). (Win64 is OK).

The problem appears to be too many asserts. I've seen this before on AppVeyor. A few intermittent asserts are OK, but a stream of them causes a failure. The asserts that are firing are alignment related in [ByteReverse](https://github.com/weidai11/cryptopp/blob/master/misc.h#L2207) and [IteratedHash](https://github.com/weidai11/cryptopp/blob/master/iterhash.h#L154):

```
// misc.h
template <class T>
void ByteReverse(T *out, const T *in, size_t byteCount)
{
    // Alignment check due to Issues 690
    CRYPTOPP_ASSERT(byteCount % sizeof(T) == 0);
    CRYPTOPP_ASSERT(IsAligned<T>(in));
    CRYPTOPP_ASSERT(IsAligned<T>(out));

    size_t count = byteCount/sizeof(T);
    for (size_t i=0; i<count; i++)
        out[i] = ByteReverse(in[i]);
}
```

And:

```
// iterhash.h
inline void CorrectEndianess(HashWordType *out, const HashWordType *in, size_t byteCount)
{
    CRYPTOPP_ASSERT(in != NULLPTR);
    CRYPTOPP_ASSERT(out != NULLPTR);
    CRYPTOPP_ASSERT(IsAligned<T_HashWordType>(in));
    CRYPTOPP_ASSERT(IsAligned<T_HashWordType>(out));

    ConditionalByteReverse(T_Endianness::ToEnum(), out, in, byteCount);
}
```

Tracing things back, it looks like `GetAlignmentOf<T>` is going a bit sideways. For example, for `word64` array, the compiler lays out an array aligned on 4 bytes (recall this is a 32-bit problem). However, `GetAlignmentOf<T>` is returning 8 because of `__alignof(T)` from [misc.h](https://github.com/weidai11/cryptopp/blob/master/misc.h#L1178):

```
// misc.h
template <class T>
inline unsigned int GetAlignmentOf()
{
#if defined(CRYPTOPP_CXX11_ALIGNOF)
	return alignof(T);
#elif (_MSC_VER >= 1300)
	return __alignof(T);
#elif defined(__GNUC__)
	return __alignof__(T);
#elif defined(__SUNPRO_CC)
	return __alignof__(T);
#elif defined(__IBM_ALIGNOF__)
	return __alignof__(T);
#elif CRYPTOPP_BOOL_SLOW_WORD64
	return UnsignedMin(4U, sizeof(T));
#else
	return sizeof(T);
#endif
}
```

`GetAlignmentOf<word64>` returns 8. I think this is actually just a symptom. I _think_ the real problem is `IsAligned<T>` from [misc.h](https://github.com/weidai11/cryptopp/blob/master/misc.h#L1219):

```
// misc.h
template <class T>
inline bool IsAligned(const void *ptr)
{
	return IsAlignedOn(ptr, GetAlignmentOf<T>());
}
```

Notice the function calls accepts a pointer and calls `GetAlignmentOf<T>`, and not the pointer-to-T `GetAlignmentOf<T*>`. Switching to a pointer-to-T with `GetAlignmentOf<T*>` clears the asserts. This makes sense since a pointer only needs to be aligned to 32-bits on a 32-bit platform. And on 64-bits, pointers are 64-bits which coincides with the `sizeof(word64)`, so everything is OK.

I also noticed the same behavior on 32-bit Linux. Those same asserts are firing, so it is not a Windows-specific problem.

My question is, why are we using `GetAlignmentOf<T>` instead of the pointer-to-T `GetAlignmentOf<T*>`? What insight did Wei have, or what was Wei trying to achieve by increasing alignment requirements for 64-bit words?

I _think_ we should change it to pointer-to-T `GetAlignmentOf<T*>` for this test.

@mouse07410, any thoughts?

--- end body ---

The issue describes a potential bug in the Crypto++ library related to alignment checks in the `FixedSizeSecBlock` class. The problem arises from the use of `GetAlignmentOf<T>` instead of `GetAlignmentOf<T*>`, which leads to incorrect alignment checks on 32-bit platforms, causing excessive assertions and failures during testing. This could potentially lead to undefined behavior if misaligned data is accessed, but it does not directly indicate a security vulnerability. The issue is more about functionality and correctness rather than a security flaw.